Identificadores de Prueba

Las integraciones 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:

json

{
  "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.

Dos de ellos, fullName y testCaseId, se utilizan para mapear resultados de prueba a pruebas y casos de prueba, por lo que los cambios en ellos pueden causar problemas en tu flujo de trabajo. El tercero, historyId, solo lo utilizan las versiones anteriores de Allure Report.

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 integraciones de Allure utilizan diferentes combinaciones de metadatos para definir fullName. Consulta la sección para más detalles.

Si un resultado de prueba no tiene testCaseId, Allure Report usa su fullName para identificar la prueba en el historial y los reintentos, consulta Cómo identifica Allure Report las pruebas.

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 de la integración 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, se deriva de otros metadatos de prueba igualmente únicos. Estos casos se discuten 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.

Allure Report usa testCaseId para identificar las pruebas en el historial y los reintentos, consulta Cómo identifica Allure Report las pruebas. Allure TestOps lo usa para mapear resultados de prueba a casos de prueba.

TIP

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

historyId

historyId es un identificador de pruebas individuales que las integraciones de Allure calculan a partir de los metadatos y los parámetros de la prueba.

Allure Report 3 y Allure Report 2.45.0 y posteriores no usan historyId: identifican las pruebas por sí mismos, como se describe a continuación. Las integraciones siguen escribiéndolo para las versiones anteriores de Allure Report, y Allure Report 2.46.1 y posteriores lo usan para encontrar el historial registrado por esas versiones anteriores.

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.

Cómo identifica Allure Report las pruebas

Para mostrar el historial y los reintentos de una prueba, Allure Report necesita saber qué resultados de prueba pertenecen a la misma prueba. Allure Report 3 y Allure Report 2.45.0 y posteriores lo deciden por sí mismos, basándose en:

el testCaseId del resultado de prueba o, si no está establecido, su fullName,
los nombres y valores de sus parámetros, excepto los excluidos; el orden de los parámetros no importa, y los valores de los parámetros ocultos y enmascarados también se tienen en cuenta,
en Allure Report 3, su entorno, si el reporte está configurado con entornos.

Los resultados de prueba con la misma identidad se muestran como reintentos de una prueba cuando forman parte del mismo lanzamiento, y como su historial cuando provienen de lanzamientos anteriores. Cualquier cosa que cambie la identidad inicia un nuevo historial para la prueba: un testCaseId o fullName diferente, un parámetro agregado o eliminado, o un valor de parámetro modificado.

TIP

Si no quieres que cierto parámetro afecte a la identidad de la prueba, por ejemplo, una marca de tiempo, marca ese parámetro como excluido. La mayoría de las integraciones de Allure soportan esta funcionalidad.

Actualizar una integración de Allure también puede cambiar los identificadores que calcula. La referencia a continuación menciona estos cambios en las versiones recientes. Para saber cómo identificaban las pruebas las versiones anteriores de Allure Report, consulta Asegurarse de que las pruebas estén identificadas correctamente.

Referencia de Identificadores de Prueba por Framework

Esta sección documenta de qué dependen fullName y testCaseId para cada integración de framework y, cuando corresponde, qué parámetros informa la integración automáticamente.

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 a un valor anterior manualmente (esto es soportado por muchas integraciones) y evitar estas consecuencias.

C#

NUnit

fullName depende 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)
testCaseId depende de fullName
parámetros: los argumentos del método de prueba

xUnit

fullName depende de:
- nombre del ensamblado
- nombre de la clase (incluyendo namespace)
- firma del método (nombre + argumentos genéricos + tipos de parámetros)
testCaseId depende de fullName
parámetros: los argumentos de las teorías

Reqnroll/SpecFlow

fullName depende 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
testCaseId depende de fullName

Dart

package:test y flutter_test

fullName depende de:
- ruta del archivo de prueba (relativa al paquete)
- nombres de grupo
- nombre de la prueba
testCaseId depende de fullName

Go

go test

fullName depende de:
- ruta del archivo de prueba (relativa al módulo)
- nombre de la prueba, incluidos los nombres de las subpruebas
testCaseId depende de fullName

Java

WARNING

Las reglas siguientes describen Allure Java 3. Allure Java 3.0 cambió la forma de calcular algunos identificadores: en Allure Java 2.x, las integraciones para JUnit 4, TestNG y JBehave no establecían testCaseId, por lo que después de la actualización, el historial de estas pruebas comienza de nuevo. Los parámetros agregados durante la ejecución ahora también forman parte de la identidad de la prueba. Consulta Migración a Allure Java 3 para obtener más información.

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
parámetros: los valores de la fila de Examples del esquema de escenario

JBehave

fullName depende de:
- nombre de la historia
- título del escenario
testCaseId depende de fullName
parámetros: los valores de la fila de la tabla de ejemplos

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 depende de:
- nombre de la clase
- nombre del método

JUnit Jupiter

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 depende del ID único de la prueba en JUnit Platform, sin la parte que identifica una invocación de una prueba parametrizada o repetida
parámetros:
- los argumentos de los métodos @ParameterizedTest (requiere la detección automática de extensiones)
- la posición de la invocación, para pruebas parametrizadas, repetidas y otras pruebas de plantilla (por ejemplo, cambiar el orden de los valores en un @ValueSource afecta al historial)

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)

Scalatest

fullName y testCaseId dependen de:
- ID de suite
- nombre de la prueba

Spock

fullName depende de:
- nombre del paquete
- nombre de la clase
- nombre del feature (para features basados en datos, el nombre del feature, no el de la iteración)
testCaseId depende de fullName
parámetros: las variables de datos de los features basados en datos

TestNG

fullName depende de:
- nombre de clase completamente calificado (incluye paquete)
- nombre del método de prueba
testCaseId depende de:
- nombre de la clase
- nombre del método de prueba
parámetros: los parámetros del método de prueba

JavaScript

WARNING

Desde la versión 3.9.0, la mayoría de las integraciones de Allure para JavaScript incluyen el nombre del proyecto, tomado del campo name del archivo package.json más cercano, en fullName y testCaseId. Después de actualizar desde una versión anterior, el historial de las pruebas comienza de nuevo.

AVA

fullName y testCaseId dependen de:
- ruta del archivo de prueba (relativa)
- título de la prueba
Excluido:
- etiquetas/anotaciones de metadatos incrustadas en el título de la prueba

Bun

fullName y testCaseId dependen de:
- ruta del archivo de prueba
- array de nombres de suite + nombre de la prueba
Excluido:
- etiquetas/anotaciones de metadatos incrustadas en nombres de prueba

Cucumber-JS

fullName depende de:
- nombre del proyecto
- ruta relativa al archivo de feature
- nombre del escenario (procesado por Cucumber)
testCaseId depende de:
- nombre del proyecto
- ruta relativa al archivo de feature
- nombre del escenario (para esquemas de escenario, el nombre del esquema)

Cypress

fullName y testCaseId dependen de:
- nombre del proyecto
- ruta del archivo de spec
- array de nombres de suite + nombre de la prueba
Excluido:
- etiquetas/anotaciones de metadatos incrustadas en nombres de prueba

Jasmine

fullName y testCaseId dependen de:
- nombre del proyecto
- ruta del archivo de spec (relativa, opcional - puede ser undefined)
- array de nombres de suite
- el nombre del spec/prueba
Excluido:
- etiquetas/anotaciones de metadatos incrustadas en nombre del spec

Jest

fullName y testCaseId dependen de:
- nombre del proyecto
- ruta del archivo de prueba (relativa al directorio raíz de Jest)
- todos los nombres de bloques describe padres (jerarquía de suite)
- nombre de la prueba
Excluido:
- ROOT_DESCRIBE_BLOCK (nodo raíz interno de Jest)

Mocha / CodeceptJS

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

fullName y testCaseId dependen de:
- nombre del proyecto
- ruta relativa al archivo de prueba
- nombres de suite
- nombre de la prueba

Newman

fullName y testCaseId dependen de:
- nombre del proyecto
- array de nombres de colección/carpeta padre
- nombre de la solicitud

node:test

fullName y testCaseId dependen de:
- nombre del proyecto
- ruta relativa al archivo de prueba
- nombres de suite
- nombre de la prueba
Excluido:
- etiquetas/anotaciones de metadatos incrustadas en el nombre de la prueba

Playwright

fullName depende de:
- ruta del archivo de prueba
- nombres de suite
- nombre de la prueba
testCaseId depende de:
- nombre del proyecto
- ruta del archivo de prueba
- nombres de suite
- nombre de la prueba

Antes de la versión 3.12.0, fullName dependía en su lugar de la ruta del archivo de prueba y de los números de línea y columna de la función de prueba.

TestCafe

fullName y testCaseId dependen de:
- ruta del archivo del fixture (relativa)
- nombre del fixture
- nombre de la prueba
Excluido:
- etiquetas/anotaciones de metadatos incrustadas en el nombre de la prueba

Vitest

fullName y testCaseId dependen de:
- nombre del proyecto
- 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

WebdriverIO (WDIO)

fullName depende de:
- ruta del archivo de prueba (relativa, consciente de URL, elimina sufijos de posición)
- título completo de la prueba (nombres de suite + título de la prueba)
testCaseId depende de:
- título completo de la prueba (nombres de suite + título de la prueba)
- nombre del navegador o dispositivo en el que se ejecuta la prueba

PHP

Behat

Allure Behat escribe los resultados en el formato anterior de Allure 1, y Allure Report calcula fullName a partir de ellos.

fullName depende de:
- escenario regular: nombre de la suite de Behat, título del Feature, título del escenario
- esquema de escenario: nombre de la suite de Behat, ruta del archivo de Feature, número de línea
testCaseId no está establecido (los tags configurados mediante test_id_tag_prefix agregan enlaces TMS, no afectan a la identidad de la prueba)

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
parámetros: solo los agregados mediante Allure::parameter(), consulta Pruebas parametrizadas

Python

Behave

fullName y testCaseId dependen de:
- nombre del feature
- nombre del escenario
Excluido:
- parámetros (solo se usa el nombre base del escenario)
parámetros: parámetros del esquema de escenario (la sección Examples)

Antes de la versión 2.15.1, Allure Behave no establecía testCaseId, por lo que después de actualizar desde una versión anterior, el historial de las pruebas comienza de nuevo.

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
parámetros:
- 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)
parámetros:
- 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 aquellos con excluded establecido en True)

Robot Framework

fullName depende del 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 fullName

Antes de la versión 2.15.2, Allure Robot Framework no establecía testCaseId, por lo que después de actualizar desde una versión anterior, el historial de las pruebas comienza de nuevo.

Ruby

Cucumber

fullName depende del nombre del escenario
testCaseId no está establecido (la etiqueta allure_id se usa para los planes de pruebas, no afecta a la identidad de la prueba)
parámetros: los valores de la fila de Examples del esquema de escenario

RSpec

fullName depende de 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 está establecido (la etiqueta allure_id se usa para los planes de pruebas, no afecta a la identidad de la prueba)

Rust

Pruebas de Rust (allure-cargotest)

fullName depende de:
- ruta del módulo
- nombre de la función de prueba
testCaseId depende de fullName

Identificadores de Prueba ​

Tipos de Identificadores ​

fullName ​

testCaseId ​

historyId ​

uuid ​

Cómo identifica Allure Report las pruebas ​

Referencia de Identificadores de Prueba por Framework ​

C# ​

NUnit ​

xUnit ​

Reqnroll/SpecFlow ​

Dart ​

package:test y flutter_test ​

Go ​

go test ​

Java ​

Cucumber JVM ​

JBehave ​

JUnit4 ​

JUnit Jupiter ​

Karate ​

Scalatest ​

Spock ​

TestNG ​

JavaScript ​

AVA ​

Bun ​

Cucumber-JS ​

Cypress ​

Jasmine ​

Jest ​

Mocha / CodeceptJS ​

Newman ​

node:test ​

Playwright ​

TestCafe ​

Vitest ​

WebdriverIO (WDIO) ​

PHP ​

Behat ​

Codeception ​

PHPUnit ​

Python ​

Behave ​

pytest ​

pytest-bdd ​

Robot Framework ​

Ruby ​

Cucumber ​

RSpec ​

Rust ​

Pruebas de Rust (allure-cargotest) ​

Powered by

Suscríbete a nuestro boletín

Allure TestOps

Compañía