Mejorando la Navegación en tu Reporte de Prueba

Un proyecto lo suficientemente grande puede tener cientos o incluso miles de pruebas. Al recopilar información sobre las pruebas, Allure puede organizar los resultados en estructuras de árbol fáciles de comprender. Con tal estructura, un lector del reporte de prueba puede navegar fácilmente a los resultados de prueba que necesita. Diferentes jerarquías pueden ser convenientes para diferentes roles en el mismo equipo: por ejemplo, un ingeniero de pruebas puede prestar más atención al árbol de Comportamientos, mientras que un desarrollador analiza el árbol de Suites, etc.

Allure 3 soporta una variedad de formas para organizar los resultados de prueba, todas definidas por la configuración de la herramienta.

Puedes elegir la que mejor se alinee con el flujo de trabajo de desarrollo en tu proyecto. Para cada jerarquía, Allure espera que los autores de pruebas asignen campos específicos a las pruebas. Las funciones exactas que deberían usarse para asignar los campos varían entre diferentes adaptadores de Allure.

INFO

Este artículo describe jerarquías que se construyen basadas en la información sobre las pruebas mismas. Para una jerarquía basada en los errores de prueba, ve Categorías de defectos.

Jerarquía Basada en Comportamiento

Épicas, características e historias de usuario son términos ampliamente usados para describir las características de un software y organizar pruebas para dichas características. Usualmente, una épica es un gran conjunto de características que el equipo busca desarrollar y probar, y una característica se describe como un conjunto de historias de usuario que describen cómo se espera que el software se comporte en diferentes escenarios.

Los adaptadores de Allure para todos los frameworks de prueba proporcionan formas de indicar la épica, característica e historia de usuario de una prueba. Si un framework de pruebas permite al autor definir algunos de estos términos nativamente, por ejemplo, en su propio formato de archivo agnóstico de lenguaje, entonces Allure hace su mejor esfuerzo para incorporar los datos proporcionados en la estructura de árbol generada. Ve la documentación del adaptador específico de Allure para más detalles.

Jerarquía Basada en Suites

Una suite de prueba es un término abstracto para cualquier grupo de pruebas, con su significado real dependiendo de las especificidades de tu proyecto.

Los adaptadores de Allure para todos los frameworks de prueba proporcionan formas de indicar la suite de una prueba, con la mayoría de ellos también proporcionando formas de indicar suites padre y sub-suites, para un total de hasta tres niveles de jerarquía. Ten en cuenta, sin embargo, que la implementación puede diferir en cómo se eligen los valores por defecto para estos campos basados en los datos proporcionados por el framework de pruebas mismo. Ve la documentación del adaptador específico de Allure para más detalles.

Jerarquía Basada en Paquetes

En algunos proyectos, es conveniente organizar las pruebas por paquetes, siguiendo de cerca la estructura del código. Para colocar una prueba en el árbol en la pestaña de Paquetes, Allure normalmente usa los nombres reales del módulo y la función en la que la prueba está implementada.

Algunos adaptadores de Allure permiten anular este comportamiento. Sin embargo, se recomienda seguir siempre la convención de nomenclatura jerárquica para paquetes, con nombres de subpaquetes colocados después de nombres de paquetes, separados por puntos.

En el árbol, los prefijos comunes de los paquetes se muestran como sus paquetes padre.

Omitir Niveles de Árbol

En todas las jerarquías descritas arriba, ninguno de los campos es necesario.

Para determinar la ubicación de una prueba en la jerarquía de Suites o Comportamientos, Allure verifica los campos relevantes en el orden predefinido:

• para jerarquía basada en comportamiento: épica, característica, historia de usuario,
• para jerarquía basada en suites: suite padre, suite, sub-suite.

Para cada campo proporcionado, Allure crea un subárbol en el árbol de resultados de prueba. Si el campo no fue proporcionado, la creación del subárbol se omite.

En el ejemplo debajo (escrito en Java usando Allure JUnit 5), la segunda prueba solo tiene el campo feature. En el reporte, su característica se muestra en el nivel superior, esencialmente convirtiéndose en la épica de esta prueba.

import io.qameta.allure.Epic;
import io.qameta.allure.Feature;
import io.qameta.allure.Story;
import org.junit.jupiter.api.DisplayName;
import org.junit.jupiter.api.Test;

public class AllureNavigationTest {

    @Test
    @Epic("Interfaz web")
    @Feature("Características esenciales")
    @Story("Autenticación")
    @DisplayName("Iniciar sesión con nombre de usuario y contraseña")
    public void testLogInWithUsernameAndPassword() {
        // ...
    }

    @Test
    @Feature("API móvil")
    @DisplayName("API: Leer perfil de usuario")
    public void testReadUserProfile() {
        // ...
    }
}