Análisis de tests de Bazel
- Un espacio de trabajo de Bazel conectado mediante
tuist bazel setup, como se describe en Primeros pasos con un proyecto de Bazel.
tuist bazel setup configura el informe por caso en .bazelrc.tuist, de modo que un bazel test normal envía casos de test individuales a los mismos paneles que usan todos los demás sistemas de compilación:
bazel test //app:tests
Para aplicar también la cuarentena, ejecuta los tests a través del wrapper de Tuist. Los argumentos que van después de -- se reenvían a bazel test:
tuist bazel test -- //app:tests
Qué se registra#
Tuist analiza los informes test.xml y captura la salida de test.log que Bazel genera para cada objetivo de test; luego los consolida en el modelo compartido de ejecuciones de tests. Cada ejecución registra:
- El estado de aprobado, fallido y omitido de cada caso de test, junto con su duración.
- La estructura de objetivos de test, clases y suites.
- Los intentos de reintento, cuando Bazel está configurado para reintentar tests inestables.
- La salida de error, capturada desde el
test.logdel objetivo.
Las páginas de Ejecuciones de tests, Casos de test y de tests individuales funcionan igual para Bazel que para otros sistemas de compilación.
Generación de informes JUnit por caso#
Las filas por caso dependen de que el objetivo de test escriba un JUnit test.xml en la ruta $XML_OUTPUT_FILE que proporciona Bazel. Cuando el runner no escribe uno, Bazel recurre a un informe sintetizado de un solo caso con el nombre del objetivo, y Tuist muestra una única fila por objetivo (etiquetada como Objetivo de Bazel en la lista de Casos de test) con el test.log sin procesar aún disponible en la página de la ejecución.
La mayoría de las reglas de test de Bazel ya producen un test.xml real:
java_testykt_jvm_test: JUnit está integrado.cc_testcon GoogleTest: el runner escribe JUnit cuando se compila contra una versión reciente de gtest; las configuraciones más antiguas necesitan--gtest_output=xml:$XML_OUTPUT_FILE.py_test: usa pytest con--junitxml=$XML_OUTPUT_FILE, o el runner pytest derules_python.go_test: canalizago test -jsona través degotestsum --junitfile=$XML_OUTPUT_FILE, o envuélvelo con un helper que emita JUnit.
rust_test de rules_rust y rules_rs ejecuta el harness estándar libtest, que no escribe JUnit en Rust estable. Envuelve el objetivo de test con un script que analice la salida de libtest y escriba JUnit en $XML_OUTPUT_FILE; así mantienes las filas por caso en Tuist y la misma ejecución sigue siendo un único objetivo de test de Bazel.
Identidad del test#
Los casos se identifican por la etiqueta del objetivo, el nombre de la clase (con fallback al nombre de la suite) y el nombre del test. Esto mantiene separados los métodos con el mismo nombre en distintas clases. Los informes antiguos que usaban un nombre de suite contenedora diferente conservan su historial bajo la identidad antigua; los cambios de estado aplicados a la identidad antigua deben volver a aplicarse a la nueva, y el comando te avisa cuando un fallo coincide con una identidad antigua para que sepas qué política trasladar.
Proporcionar contexto de CI#
Tuist lee la información del commit y la rama de git a partir de los metadatos de compilación de Bazel, de modo que las ejecuciones en el mismo commit puedan compararse entre entornos. La mayoría de los sistemas de integración continua ya los establecen; cuando el tuyo no lo haga, pásalos explícitamente:
tuist bazel test -- \
--build_metadata=CI=true \
--build_metadata=GIT_COMMIT="$GIT_COMMIT" \
--build_metadata=GIT_BRANCH="$GIT_BRANCH" //app:tests
La misma bandera --build_metadata es la que describe la página de Análisis de compilaciones de Bazel para etiquetar invocaciones, así que un único conjunto de banderas cubre ambas superficies.
Tests inestables y cuarentena#
Los reintentos, la detección de inestabilidad entre ejecuciones y la cuarentena por caso (Silenciar y Omitir) funcionan a través de tuist bazel test. Consulta Tests inestables de Bazel para ver el flujo completo.
Retención de datos#
Tuist conserva durante 90 días la invocación de Bazel que generó una ejecución de test, sus registros y los registros pendientes de ingesta de tests. Los casos de test y su historial de ejecuciones usan el mismo modelo que cualquier otro sistema de compilación y no están sujetos a ese periodo. Consulta retención de datos para conocer la política completa.