Resoluciones Allure 3

No todas las pruebas fallidas necesitan una investigación nueva. Una falla puede ya estar reportada como un bug, estar ignorada temporalmente mientras alguien trabaja en una corrección, o ser esperada en el contexto actual. Las resoluciones te permiten marcar dichas fallas en el archivo de configuración de Allure. En el reporte, las fallas con una resolución obtienen un ícono en el árbol de pruebas y se agrupan en la pestaña Resolutions, y puedes seleccionarlas con el filtro Resolution. Los contadores Failed y Broken solo muestran las fallas que todavía necesitan atención. Consulta Resoluciones en el reporte para más detalles.

Una resolución es asignada por una regla que coincide con los resultados de prueba según su mensaje de error, el ID del caso de prueba, el hash del reintento o el entorno. Las resoluciones se aplican solo a resultados de prueba fallidos y rotos: un resultado aprobado u omitido nunca obtiene una resolución, aunque coincida con una regla.

Tipos de resolución

Hay tres tipos de resolución:

Resolución	Úsala para	Campos requeridos	Contada por los quality gates
issue	Una falla causada por un bug conocido que se rastrea en un sistema de seguimiento de incidencias.	issue	Sí
muted	Una falla que quieres ignorar temporalmente, por ejemplo, mientras se corrige la prueba.	comment	No
accepted	Una falla que es esperada, por ejemplo, una funcionalidad que todavía no está disponible.	comment	No

Configurar resoluciones

Agrega la sección resolutions al archivo de configuración. Contiene una lista de rules y, opcionalmente, plantillas de links que convierten los IDs de incidencias en enlaces clicables:

allurerc.mjs

import { defineConfig } from "allure";

export default defineConfig({
  resolutions: {
    links: {
      jira: {
        urlTemplate: "https://jira.example.com/browse/%s",
        nameTemplate: "JIRA %s",
      },
    },
    rules: [
      {
        resolution: "issue",
        issue: { id: "SHOP-42", type: "jira" },
        messageRegexp: "Connection timeout",
        comment: "Payment gateway sandbox is slow",
      },
      {
        resolution: "muted",
        testCaseId: ["103"],
        comment: "Muted until the widget redesign lands",
      },
      {
        resolution: "accepted",
        environment: ["windows"],
        messageRegexp: "^Export format",
        comment: "The v1 export format is expected on Windows",
      },
    ],
  },
});

allurerc.json

{
  "resolutions": {
    "links": {
      "jira": {
        "urlTemplate": "https://jira.example.com/browse/%s",
        "nameTemplate": "JIRA %s"
      }
    },
    "rules": [
      {
        "resolution": "issue",
        "issue": { "id": "SHOP-42", "type": "jira" },
        "messageRegexp": "Connection timeout",
        "comment": "Payment gateway sandbox is slow"
      },
      {
        "resolution": "muted",
        "testCaseId": ["103"],
        "comment": "Muted until the widget redesign lands"
      },
      {
        "resolution": "accepted",
        "environment": ["windows"],
        "messageRegexp": "^Export format",
        "comment": "The v1 export format is expected on Windows"
      }
    ]
  }
}

allurerc.yaml

resolutions:
  links:
    jira:
      urlTemplate: https://jira.example.com/browse/%s
      nameTemplate: JIRA %s
  rules:
    - resolution: issue
      issue:
        id: SHOP-42
        type: jira
      messageRegexp: Connection timeout
      comment: Payment gateway sandbox is slow
    - resolution: muted
      testCaseId: ["103"]
      comment: Muted until the widget redesign lands
    - resolution: accepted
      environment: [windows]
      messageRegexp: ^Export format
      comment: The v1 export format is expected on Windows

Cada regla contiene:

• resolution - issue, muted o accepted.
• uno o más matchers que seleccionan los resultados de prueba.
• issue (solo para reglas issue) - un objeto con el id de la incidencia y el type, que debe ser una de las claves de links. Cada ID de incidencia puede usarse solo en una regla.
• comment - una explicación mostrada en el reporte. Requerido para las reglas muted y accepted, opcional para las reglas issue.

Allure valida la configuración de resoluciones al iniciar. Si la configuración no es válida (por ejemplo, una regla no tiene matchers, o una regla muted no tiene comentario), el comando falla con un error que lista todos los problemas:

The provided resolutions config is invalid: resolutions.rules[1].comment must be a non-empty string

Matchers

Una regla debe contener al menos un matcher. Si una regla contiene varios matchers, un resultado de prueba debe satisfacer todos ellos. Los matchers que toman una lista se satisfacen si cualquiera de los valores listados coincide.

Matcher	Tipo	Coincide con un resultado de prueba si...
messageRegexp	string	su mensaje de error coincide con la expresión regular de JavaScript. La expresión no está anclada: "timeout" coincide con cualquier mensaje que contenga timeout.
testCaseId	string[]	su ID de caso de prueba está en la lista. Cualquiera de estos IDs funciona: el ID de caso de prueba calculado por Allure, la etiqueta de ID de la prueba (ALLURE_ID), o el ID de caso de prueba reportado por la integración de Allure.
retryHash	string[]	su hash de reintento está en la lista. El hash de reintento identifica una prueba específica con parámetros específicos en un entorno específico.
environment	string[]	su ID de entorno está en la lista.

Para encontrar el ID de caso de prueba o el hash de reintento de una prueba, abre la prueba en el reporte y pasa el cursor sobre el ícono de copiar junto a su nombre completo. El menú te permite copiar el nombre completo, el Test case ID o el Retry hash.

TIP

Usa testCaseId para hacer coincidir una prueba sin importar sus parámetros y entorno, y retryHash para hacer coincidir solo una variante específica de una prueba parametrizada o solo un entorno. Ten en cuenta que el hash de reintento de la misma prueba difiere entre entornos.

Enlaces de incidencias

La sección links define una plantilla para cada tipo de incidencia que uses. La clave (jira en los ejemplos anteriores) es el tipo al que te refieres en el campo issue.type de las reglas.

• urlTemplate (requerido) - la URL de la incidencia, con exactamente un marcador de posición %s para el ID de la incidencia. La URL resultante debe ser una URL absoluta http:// o https://.
• nameTemplate (opcional) - el texto del enlace, con exactamente un marcador de posición %s para el ID de la incidencia. Si se omite, el propio ID de la incidencia se usa como texto del enlace.

Con la configuración anterior, la incidencia SHOP-42 se muestra en el reporte como un enlace JIRA SHOP-42 a https://jira.example.com/browse/SHOP-42.

Prioridad de reglas

Un resultado de prueba puede obtener solo una resolución. Si coincide con varias reglas, Allure elige la resolución en este orden:

1. La primera regla issue que coincida.
2. La bandera muted establecida en el propio resultado de prueba (consulta Resoluciones desde resultados de prueba).
3. La bandera known establecida en el propio resultado de prueba.
4. La primera regla muted que coincida.
5. La primera regla accepted que coincida.

Por ejemplo, si una falla está vinculada a una incidencia y también coincide con una regla muted, el reporte la muestra como vinculada a la incidencia.

Resoluciones desde resultados de prueba

Un archivo de resultado de prueba también puede marcar una falla como silenciada o conocida por sí mismo, mediante la bandera muted o known en su statusDetails. Allure Report 3 convierte estas banderas en resoluciones:

• un resultado con "muted": true obtiene la resolución Muted con el comentario "Muted from result";
• un resultado con "known": true obtiene la resolución Accepted con el comentario "Accepted from result (known)".

Esto funciona incluso si el archivo de configuración no tiene una sección resolutions.

Resoluciones en el reporte

Los resultados de prueba con una resolución se marcan con un ícono en el árbol de pruebas: un bug para Issue, un ojo para Muted, y una marca de verificación para Accepted.

Filtro de resolución. Usa el menú desplegable Resolution sobre el árbol de pruebas para mostrar solo los resultados de prueba con las resoluciones seleccionadas. Además de los tres tipos de resolución, tiene la opción No resolution, que muestra los resultados de prueba fallidos y rotos que todavía no tienen una resolución - las fallas que todavía necesitan atención.

Contadores y filtros de estado. Los resultados de prueba fallidos y rotos que tienen una resolución no se incluyen en los contadores Failed y Broken en el lado derecho del resumen, y los filtros de estado Failed y Broken sobre el árbol muestran solo las fallas sin resolución. Para ver las fallas resueltas, usa el filtro Resolution.

Pestaña Resolutions. La pestaña Resolutions del reporte agrupa los resultados de prueba resueltos: un grupo por incidencia, con su enlace, tipo y comentario, luego un grupo Muted o Accepted por comentario.

Página de prueba. La página de un resultado de prueba resuelto tiene una pestaña Resolutions con la resolución, el enlace de la incidencia (para issue) y el comentario.

Resoluciones y quality gates

Las reglas de quality gate ignoran las fallas con las resoluciones Muted y Accepted: no cuentan hacia maxFailures, successRate ni ninguna otra regla. Las fallas vinculadas a una Issue sí cuentan, porque el bug al que apuntan todavía existe.

La tasa de éxito mostrada en el gráfico circular del reporte también las excluye.

Cuando ejecutas pruebas con allure run --rerun, las fallas silenciadas y aceptadas no se vuelven a ejecutar.

Archivo de problemas conocidos

Cada vez que Allure genera un reporte con resoluciones configuradas, también escribe un archivo de problemas conocidos: un archivo JSON con las incidencias a las que están vinculadas las fallas de la ejecución, y los resultados de prueba fallidos y rotos vinculados a cada una de ellas. Puedes procesar este archivo en tu pipeline de CI, por ejemplo, para publicar la lista de problemas conocidos en un chat.

Por defecto, el archivo se escribe en known-issues.json en el directorio de trabajo actual. Puedes cambiar la ruta en el archivo de configuración o con la opción de línea de comandos --known-issues; la ruta debe terminar en .json:

import { defineConfig } from "allure";

export default defineConfig({
  resolutions: {
    knownIssuesPath: "./out/known-issues.json",
    rules: [
      // ...
    ],
  },
});

allure generate --known-issues ./out/known-issues.json ./allure-results

El archivo es solo de salida: Allure no lo vuelve a leer. Para marcar fallas como conocidas, usa reglas de resolución. El archivo no forma parte del reporte generado, por lo que tampoco se publica en el Almacenamiento de Reportes de Allure.

Resoluciones en builds multietapa

Los archivos de volcado almacenan las resoluciones asignadas durante cada etapa. Cuando construyas el reporte final a partir de los archivos de volcado, usa la misma configuración de resolutions que en las etapas, para que el reporte final muestre las mismas resoluciones.

Migración desde el archivo de problemas conocidos

Versiones anteriores de Allure Report 3 admitían problemas conocidos mediante un archivo JSON con una lista de valores historyId, configurado con la opción de nivel superior knownIssuesPath y creado con el comando allure known-issue. Ambos han sido reemplazados por resoluciones: un archivo de configuración que todavía contiene la opción de nivel superior knownIssuesPath hace que Allure falle con el error "unsupported fields: knownIssuesPath".

Para migrar:

1. Elimina la opción de nivel superior knownIssuesPath del archivo de configuración.
2. Para cada problema conocido, agrega una regla issue a resolutions.rules. Haz coincidir las pruebas por testCaseId, retryHash o messageRegexp en lugar de historyId.
3. Agrega una plantilla de links para tu sistema de seguimiento de incidencias.
4. Si usabas el archivo de problemas conocidos para ignorar fallas sin vincularlas a incidencias, usa reglas muted o accepted en su lugar.