Configuración de pruebas en Go

La integración allure-go se configura mediante variables de entorno.

ALLURE_RESULTS_DIR

Sobrescribe el directorio predeterminado donde la integración escribe los resultados de Allure.

Si no se establece, los resultados se escriben en allure-results, resuelto en relación al directorio de trabajo de cada binario de prueba. Go ejecuta cada binario de prueba en el directorio fuente de su paquete, así que en un módulo con varios paquetes de prueba, establece esta variable con una ruta absoluta para recopilar todos los resultados en un solo directorio:

ALLURE_RESULTS_DIR=$PWD/allure-results go test ./...

ALLURELABEL*

Agrega etiquetas globales a cada resultado de prueba.

Cualquier variable de entorno cuyo nombre comience con ALLURE_LABEL_ se convierte en una etiqueta de Allure. Por ejemplo:

ALLURE_LABEL_EPIC="Interfaz web" \
ALLURE_LABEL_OWNER="Equipo QA" \
go test ./...

Esto aplica las etiquetas epic y owner a cada prueba en la ejecución.

Los nombres de las etiquetas se normalizan al estilo camel case inferior de Allure: el nombre después del prefijo se convierte en minúsculas, y los guiones bajos y guiones inician una nueva palabra capitalizada. Por ejemplo, ALLURE_LABEL_MODULE=commons se convierte en la etiqueta module=commons, y ALLURE_LABEL_PARENT_SUITE=runtime se convierte en parentSuite=runtime. Las variables con valores vacíos se ignoran.

ALLURE_TESTPLAN_PATH

Apunta a un archivo JSON que define qué pruebas deben ejecutarse.

El archivo utiliza la forma estándar del plan de pruebas de Allure:

{
  "version": "1.0",
  "tests": [
    { "id": "123" },
    { "selector": "example/login_test.go/TestLogin/logs_in_with_valid_credentials" }
  ]
}

Ejecuta las pruebas con:

ALLURE_TESTPLAN_PATH=./testplan.json go test ./...

La selección funciona de la siguiente manera:

• las entradas con id coinciden con pruebas que declaran un Allure ID, por ejemplo mediante allure.WithAllureID("123") o un tag @allure.id=123,
• las entradas con selector coinciden con el nombre completo de la prueba: la ruta del archivo de prueba relativa a la raíz del módulo, seguida por el nombre completo de la prueba en Go, unidos con /. Por ejemplo, una prueba declarada como allure.Test(t, "logs in", ...) dentro de TestLogin en example/login_test.go tiene el nombre completo example/login_test.go/TestLogin/logs_in.

Las pruebas no seleccionadas por el plan se omiten con t.Skip antes de que se ejecute su cuerpo. Solo la metainformación conocida antes de ejecutar el cuerpo de la prueba participa en la selección: opciones estáticas allure.With... y variables ALLURE_LABEL_*. Un Allure ID establecido en tiempo de ejecución con a.Label(...) es demasiado tarde para afectar el filtrado.

Si ALLURE_TESTPLAN_PATH no está definido o el archivo no contiene entradas de prueba, todas las pruebas se ejecutan normalmente. Si el archivo no puede leerse o contiene JSON inválido, cada prueba reportada falla y se escribe en los resultados como rota, así que un plan de pruebas mal configurado no ejecuta ni omite silenciosamente toda la suite.

Etiquetas e identificadores automáticos

La integración agrega dos etiquetas a cada resultado de prueba automáticamente:

• language = go
• framework = go-test

También deriva etiquetas de suite a partir de la ruta del archivo de prueba relativa a la raíz del módulo (el directorio que contiene go.mod):

• un solo segmento de ruta se convierte en suite,
• dos segmentos se convierten en parentSuite y suite,
• tres o más segmentos se convierten en parentSuite, suite y subSuite (los segmentos restantes unidos con >).

Por ejemplo, una prueba en commons/gotest/allure_test.go obtiene parentSuite = commons, suite = gotest y subSuite = allure_test.go. Establecer cualquiera de las etiquetas parentSuite, suite o subSuite explícitamente — mediante opciones como allure.WithSuite(...), llamadas en tiempo de ejecución o variables ALLURE_LABEL_* — desactiva la derivación automática por completo.

Finalmente, a menos que se establezca explícitamente, el testCaseId de cada resultado se calcula a partir del nombre completo de la prueba, y su historyId se calcula a partir del testCaseId y los parámetros de la prueba (los parámetros marcados como excluidos no lo afectan). Estos identificadores mantienen los reintentos, el historial y las gráficas de tendencias estables entre ejecuciones.