Identificadores de Prueba

Los adaptadores de Allure y las herramientas de reporte de Allure utilizan identificadores internos de prueba para rastrear las pruebas a través de las ejecuciones y mapear correctamente los resultados históricos dentro de los reportes.

Este artículo explica cómo funcionan estos identificadores internos y qué partes de tu flujo de trabajo de pruebas pueden verse afectadas por cualquier cambio en ellos.

TIP

Este artículo hace referencia frecuentemente a conceptos como casos de prueba, pruebas y resultados de prueba. Por favor, consulta el Glosario para conocer exactamente qué significan estos términos dentro de Allure Report.

Tipos de Identificadores

Hay cuatro identificadores principales que las herramientas de Allure utilizan para rastrear los resultados de prueba.

• fullName
• testCaseId
• historyId
• uuid

Aquí hay un ejemplo de un archivo de resultado de prueba de Allure (típicamente encontrado dentro del directorio allure-results de tu proyecto) donde se almacenan todos estos identificadores:

{
  "name": "test_sum_keyword[sum_arguments1]",
  "status": "passed",
  "parameters": [
    {
      "name": "sum_arguments",
      "value": "[-1, 1, 0]"
    }
  ],
  "start": 1759304434025,
  "stop": 1759304434025,
  "uuid": "2f25f93b-9ef3-4e62-b4d7-e376db69e198",
  "historyId": "741e3c0379dae9c479f495d79cfc4a46",
  "testCaseId": "e3edbc90111b1e74614910797ec9e808",
  "fullName": "test.test_sum#test_sum_keyword",
  "labels": [
    {
      "name": "parentSuite",
      "value": "test"
    },
    {
      "name": "suite",
      "value": "test_sum"
    },
    {
      "name": "package",
      "value": "test.test_sum"
    }
  ]
}

Los cuatro son identificadores opacos que se calculan para cada resultado de prueba automáticamente y no se muestran, usualmente, en los reportes generados.

Sin embargo, como se basan en metadatos del framework de pruebas, pueden cambiar cuando refactorizas tu código de prueba.

Tres de los cuatro (fullName, testCaseId, historyId) se utilizan para mapear resultados de prueba a pruebas, por lo que los cambios en ellos pueden causar problemas en tu flujo de trabajo.

A continuación discutimos cómo se calcula cada identificador y qué afecta.

fullName

fullName identifica casos de prueba y siempre se calcula según dos reglas:

• debe ser único para cada caso de prueba en el proyecto
• para casos de prueba parametrizados no debe depender de los valores de los parámetros

Típicamente es una cadena de texto que consiste en metadatos de prueba concatenados proporcionados por el framework de pruebas (por ejemplo, nombre del paquete + clase + nombre de prueba).

Diferentes adaptadores de Allure utilizan diferentes combinaciones de metadatos para definir fullName. Consulta la sección para más detalles.

fullName es el identificador utilizado por las herramientas de reporte de Allure para realizar ejecuciones selectivas de pruebas:

• Allure Report 3 usa fullName para identificar qué casos de prueba volver a ejecutar.

Ejemplo

Ejecutas tus pruebas de JavaScript así: npx allure run --rerun 5 -- npm test. Esto significa que si algún caso de prueba falla durante la ejecución inicial, quieres que Allure los vuelva a ejecutar hasta 5 veces. Cuando la primera ejecución se completa, Allure recopila los identificadores fullName de las pruebas fallidas y crea un plan de pruebas con estos identificadores, que luego vuelve a ejecutar.

• Allure TestOps usa fullName para ejecutar casos de prueba seleccionados desde un plan de pruebas o lanzamiento.

• También puedes crear un archivo de plan de prueba con identificadores fullName manualmente y ejecutarlo a través del adaptador de Allure de tu framework de pruebas.

En los tres casos, puedes encontrar problemas si el identificador fullName de alguna prueba cambia, es decir, si refactorizas tu código (por ejemplo, renombrar algunas funciones de prueba, reorganizar archivos de prueba), entre el momento en que el identificador se guardó en un plan de prueba y el momento en que el plan de prueba se utiliza para volver a ejecutar las pruebas.

Si esto es algo que puede suceder en tu proyecto, la mejor práctica es asignar etiquetas ALLURE_ID a las pruebas afectadas: si esa etiqueta está presente, anula fullName como el identificador principal del caso de prueba para los planes de prueba, y no cambia cuando reorganizas tu código de cualquier manera.

TIP

La semántica exacta de cómo cada framework calcula fullName está sujeta a cambios. Por ejemplo, el orden en que se concatenan las cadenas, o los caracteres utilizados como separadores pueden revisarse en algún momento para tener en cuenta algunos casos extremos en la nomenclatura. Por eso este documento detalla qué metadatos se incluyen en fullName para diferentes frameworks, pero no cómo exactamente se construye.

Y por esta misma razón, aconsejamos no construir integraciones personalizadas basadas en la estructura exacta de fullName.

testCaseId

testCaseId identifica casos de prueba y generalmente es un hash de fullName. En algunos casos raros, es un hash derivado de metadatos de prueba igualmente únicos. Estos casos se discutirán a continuación.

Al igual que fullName, testCaseId es un identificador opaco que no está destinado a ser legible para humanos.

En la mayoría de los casos, la refactorización de código que hace que fullName para un caso de prueba cambie también cambiará testCaseId.

Actualmente, solo se usa para mapear resultados de prueba a casos de prueba en la base de datos de Allure TestOps, pero en futuras versiones su uso se expandirá.

TIP

A diferencia de fullName, puedes establecer testCaseId a través de API en algunos adaptadores de framework. Para más detalles, consulta la documentación específica del framework.

historyId

historyId identifica pruebas individuales.

Se utiliza para rastrear el historial de resultados de prueba para una prueba específica con el mismo conjunto de parámetros (y mostrar resultados anteriores en las pestañas History and Retries en Allure Report).

• depende de todos los mismos metadatos de los que dependen fullName y testCaseId
• a diferencia de fullName y testCaseId, adicionalmente depende de los parámetros

Donde un caso de prueba parametrizado tendrá el mismo fullName y testCaseId en todas las variaciones de parámetros, historyId será único para cada combinación única de parámetros. Y cada vez que cambia el valor de un parámetro de prueba, historyId para esta prueba también cambia.

TIP

Si no quieres que cierto parámetro afecte historyId, marca ese parámetro como excluido. La mayoría de los adaptadores de Allure soportan esta funcionalidad.

uuid

uuid es único para cada resultado de prueba, pero no se reutiliza a través de diferentes ejecuciones de ninguna manera. Ninguna integración existente se basa, y ninguna integración personalizada debería basarse en él para mapear resultados a pruebas, por lo que no se discutirá más en este documento.

Referencia de Identificadores de Prueba por Framework

Esta sección documenta de qué dependen los identificadores para cada adaptador de framework.

Su propósito es mostrar qué cambios a una prueba dada durante la refactorización pueden romper el historial de la prueba y/o su asociación con el caso de prueba.

Si encuentras que alguna refactorización que estás planeando afectará los identificadores, puedes establecer testCaseId/historyId a un valor anterior manualmente (esto es soportado por muchos adaptadores) y evitar estas consecuencias.

C#

NUnit

• fullName y testCaseId dependen de:
  • nombre del ensamblado
  • nombre de la clase (incluyendo namespace y argumentos de tipo genérico)
  • argumentos del test fixture (si los hay)
  • firma del método (nombre + argumentos genéricos + tipos de parámetros)
• historyId depende de:
  • fullName
  • parámetros ordenados por nombre

xUnit

• fullName y testCaseId dependen de:
  • nombre del ensamblado
  • nombre de la clase (incluyendo namespace)
  • firma del método (nombre + argumentos genéricos + tipos de parámetros)
• historyId depende de:
  • fullName
  • parámetros ordenados por nombre

Reqnroll/SpecFlow

• fullName y testCaseId dependen de:
  • nombre del ensamblado
  • ruta de la carpeta que contiene el archivo de feature
  • featureInfo.Title - el título del feature
  • scenarioTitle - el nombre del escenario
• historyId depende de:
  • fullName
  • parámetros ordenados por nombre

Java

Cucumber JVM

• fullName depende de:
  • ruta del archivo de feature (relativa)
  • número de línea del escenario
• testCaseId depende de:
  • ruta del archivo de feature
  • nombre del escenario original
• historyId depende de:
  • ruta del archivo de feature (relativa)
  • número de línea del escenario

JBehave

• fullName depende de:
  • nombre de la historia
  • título del escenario
• testCaseId no está establecido
• historyId depende de fullName y nombres y valores de parámetros no excluidos

JUnit4

• fullName depende de:
  • nombre del paquete
  • nombre de la clase
  • nombre del método
  • para pruebas de Cucumber vía JUnit4: ruta del archivo de feature o URI
• testCaseId no está establecido
• historyId depende de fullName y nombres y valores de parámetros no excluidos

JUnit5

• fullName depende de:
  • methodSource: paquete, nombre de clase, nombre de método
  • classSource: paquete, nombre de clase
  • classpathResourceSource: ruta del recurso, número de línea opcional
• testCaseId es igual al uniqueId de JUnit Platform (estable para plantillas de prueba)
• historyId es un hash del uniqueId de JUnit Platform

Karate

• fullName depende de:
  • ruta del archivo de feature (relativa)
  • número de línea del escenario
• testCaseId depende de:
  • ruta del archivo de feature
  • nombre del escenario (o número de línea como alternativa)
• historyId depende de:
  • ID único del escenario interno de Cucumber

Scalatest

• fullName, testCaseId e historyId dependen todos de:
  • ID de suite
  • nombre de la prueba

Spock

• fullName depende de:
  • nombre del paquete
  • nombre de la clase
  • nombre del feature/prueba (o nombre de iteración para pruebas parametrizadas)
• testCaseId (solo Spock 2) depende de:
  • fullName
• historyId depende de:
  • nombre calificado
  • nombres y valores de parámetros (ordenados)

TestNG

• fullName depende de:
  • nombre de clase completamente calificado (incluye paquete)
  • nombre del método de prueba
• testCaseId no está establecido
• historyId depende de fullName y nombres y valores de parámetros no excluidos

JavaScript

Cucumber-JS

• fullName y testCaseId dependen de:
  • ruta relativa al archivo de feature
  • nombre del escenario (procesado por Cucumber)
• historyId depende de fullName y nombres y valores de parámetros no excluidos

Cypress

• fullName y testCaseId dependen de:

  • ruta del archivo de spec
  • array de nombres de suite + nombre de la prueba

  Excluido:

  • etiquetas/anotaciones de metadatos incrustadas en nombres de prueba

• historyId depende de fullName y nombres y valores de parámetros no excluidos

Jasmine

• fullName y testCaseId dependen de:

  • ruta del archivo de spec (relativa, opcional - puede ser undefined)
  • array de nombres de suite + nombre de la prueba
  • el nombre del spec/prueba

  Excluido:

  • etiquetas/anotaciones de metadatos incrustadas en nombre del spec

• historyId depende de fullName y nombres y valores de parámetros no excluidos

Jest

• fullName y testCaseId dependen de:

  • nombre de la prueba
  • todos los nombres de bloques describe padres (jerarquía de suite)

  Excluido:

  • ROOT_DESCRIBE_BLOCK (nodo raíz interno de Jest)

• historyId depende de fullName y nombres y valores de parámetros no excluidos

Mocha / CodeceptJS

CodeceptJS usa Mocha internamente, por lo que las reglas de cálculo de identificadores son las mismas.

• fullName y testCaseId dependen de:
  • ruta relativa al archivo de prueba
  • nombres de suite
  • nombre de la prueba
• historyId depende de fullName y nombres y valores de parámetros no excluidos

Newman

• fullName, testCaseId e historyId dependen todos de:
  • array de nombres de colección/carpeta padre
  • nombre de request/prueba

Playwright

• fullName depende de:
  • ruta del archivo de prueba
  • número de línea de la función de prueba en el archivo fuente
  • número de columna de la función de prueba en el archivo fuente
• testCaseId depende de:
  • ruta del archivo de prueba
  • jerarquía de suite
  • nombre de la prueba
• historyId depende de testCaseId y nombres y valores de parámetros no excluidos

Vitest

• fullName y testCaseId dependen de:

  • ruta del archivo de prueba (vía relativeTestPath)
  • array de nombres de suite padre
  • nombre de la prueba

  Excluido:

  • etiquetas/anotaciones de metadatos incrustadas en nombre del spec

• historyId depende de fullName y nombres y valores de parámetros no excluidos

WebdriverIO (WDIO)

• fullName y testCaseId dependen de:
  • ruta del archivo de prueba (relativa, consciente de URL, elimina sufijos de posición)
  • título de la prueba
• historyId depende de fullName y nombres y valores de parámetros no excluidos

PHP

Behat

• fullName depende de:
  • escenario regular: título del Feature, título del escenario
  • esquema de escenario: ruta del archivo de Feature, número de línea
• testCaseId:
  • no se establece automáticamente
  • puede proporcionarse manualmente vía anotaciones @TestCaseId (almacenado como etiqueta)
• historyId no está establecido

Codeception

• fullName depende de:
  • Cept: firma integrada de Codeception
  • Cest: Namespace, nombre de clase, nombre de método
  • Unit: Namespace, nombre de clase, nombre de prueba
  • Gherkin: No establecido
• testCaseId depende de:
  • firma integrada de Codeception
  • nombres de parámetros

PHPUnit

• fullName depende de:
  • nombre de clase completamente calificado
  • nombre del método de prueba
• testCaseId depende de:
  • fullName
  • nombres de parámetros no excluidos
• historyId depende de:
  • testCaseId
  • nombre del método de prueba
  • nombres y valores de parámetros

Python

Behave

• fullName y testCaseId dependen de:

  • nombre del feature
  • nombre del escenario

  Excluido:

  • parámetros (solo se usa el nombre base del escenario)

• historyId depende de:

  • nombre del feature
  • nombre del escenario
  • parámetros del esquema de escenario (la sección Examples)

pytest

• fullName y testCaseId dependen de:

  • ruta del paquete/módulo
  • nombre de la función de prueba
  • nombres de clase - solo si la prueba está dentro de una clase (pueden ser clases anidadas)

  Excluido:

  • parámetros

• historyId depende de:

  • fullName
  • parámetros ordenados por nombre:
    • parámetros de pytest (ej., proporcionados vía @pytest.mark.parametrize)
    • parámetros de Allure (excepto aquellos con excluded establecido en True)

pytest-bdd

• fullName y testCaseId dependen de:

  • ruta relativa del archivo .feature
  • nombre del escenario

  Excluido:

  • nombre del feature (usa ruta del archivo en su lugar)
  • parámetros (solo el nombre base del escenario)

• historyId depende de:

  • testCaseId
  • parámetros ordenados por nombre:
    • parámetros de pytest (ej., proporcionados vía @pytest.mark.parametrize)
    • parámetros del esquema de escenario de la sección Examples del archivo Gherkin
    • parámetros de Allure (excepto cuando excluded está establecido en False)

Robot Framework

• fullName es igual al atributo integrado longname de Robot Framework, que es el nombre jerárquico completo de la prueba (ruta de suite + nombre de la prueba)
• testCaseId depende de:
  • nombres de suite
  • nombre del caso de prueba
• historyId es un hash de longname

Ruby

Cucumber

• fullName es igual al scenario.name integrado
• testCaseId:
  • no se establece automáticamente
  • puede proporcionarse manualmente vía etiquetas allure_id para soporte de plan de prueba
• historyId es igual al scenario.id integrado

RSpec

• fullName es igual a example.full_description (propiedad integrada de RSpec que incluye las descripciones de bloques describe anidados más la descripción de la prueba)
• testCaseId:
  • no se establece automáticamente
  • puede proporcionarse manualmente vía etiquetas allure_id para soporte de plan de prueba
• historyId depende del example.id integrado de RSpec y nombres y valores de parámetros