El problema no es que aparezca una compilación en rojo, sino saber si se debe a una nueva regresión, a una prueba intermitente o a un bloqueo del host de pruebas que eliminó las evidencias necesarias para la investigación. El .NET Blog explica cómo Microsoft.Testing.Platform, o MTP, puede hacer que los informes de pruebas sean más útiles para desarrolladores, revisores y herramientas de integración continua, en lugar de limitarse a mostrar una larga lista de registros.
Estas prácticas están dirigidas a equipos que utilizan GitHub Actions o Azure DevOps y quieren que la información sobre los fallos llegue al punto de toma de decisiones dentro de la solicitud de incorporación de cambios. La plataforma también permite generar más de un formato de informe a partir de una sola ejecución y proporcionar salidas estructuradas que los programas, los paneles y las herramientas de desarrollo puedan consumir de forma estable.
Usa el historial de compilación para distinguir entre una regresión y un fallo intermitente
Azure DevOps ya muestra las evidencias de las pruebas en la pestaña Tests, pero pasar una ventana histórica al informador añade contexto a cada fallo. Al utilizar la opción --report-azdo-flaky-history 14, la plataforma consulta el historial de la canalización durante 14 días y después distingue la prueba que falló de forma intermitente de la prueba que no tiene un historial similar.
La prueba intermitente puede aparecer con la etiqueta [flaky: failed 3/20 in last 14d], mientras que el fallo que no tiene este historial recibe la etiqueta [REGRESSION]. Esto ayuda al revisor a comenzar la investigación por el camino adecuado: un fallo sin historial requiere atención inmediata como posible regresión, mientras que un fallo recurrente se investiga a partir de su historial conocido.
Si el equipo quiere cambiar ese comportamiento de la integración continua, existe la opción --report-azdo-demote-known-flaky, que convierte los fallos conocidos como intermitentes en advertencias y mantiene las regresiones como errores. Sin embargo, la fuente subraya que la decisión debe ser explícita: ¿queremos utilizar el historial solo para orientar al revisor o queremos que cambie automáticamente el nivel de gravedad del fallo? En la canalización de testfx se utilizaron comentarios históricos manteniendo todos los estados de fallo como bloqueadores de la compilación.
El mismo historial se utiliza para detectar pruebas lentas mediante --report-azdo-slow-test-history. La opción compara cada prueba con su rendimiento anterior mediante un multiplicador configurable y un número mínimo de ejecuciones, para que una sola ejecución en frío no active una alerta imprecisa.
Conserva las evidencias cuando se bloquea el host de pruebas
Los resultados en formato TRX se serializaban al final de la ejecución, por lo que un bloqueo grave podía provocar la pérdida del informe completo. Ahora los resultados se escriben en el disco a medida que se generan y, junto con la extensión de volcado de errores, el informe parcial puede finalizarse cuando el host se detiene:
dotnet test --report-trx --crashdump
Esto produce un archivo TRX válido que incluye todas las pruebas completadas, junto con una lista de las pruebas que estaban en ejecución cuando se produjo el bloqueo. La extensión también escribe un archivo con la extensión .crash.sequence.log que registra el inicio y el final de cada prueba, lo que ayuda a identificar la prueba que comenzó y no terminó incluso cuando se ejecutan varias pruebas en paralelo.
El procesamiento también incluye los archivos adjuntos. Los volcados de errores, los comentarios de detención y los archivos de extensiones de prueba ya no se descartan silenciosamente en .NET Framework cuando la ruta supera el límite de Windows MAX_PATH. Si no se puede copiar un archivo adjunto, se muestra en la consola en lugar de quedar mencionado únicamente dentro del archivo TRX. El resultado es que una ejecución incompleta aparece claramente como incompleta y no como un informe verde que oculte evidencias faltantes.
Elige el formato del informe según su consumidor
Una sola ejecución puede activar varios formatos sin un paso de conversión separado. El formato TRX es adecuado para las herramientas de .NET, mientras que HTML sirve para la inspección directa y JUnit XML y CTRF JSON resultan útiles para paneles y automatización entre tecnologías. CTRF proporciona un esquema JSON común para agregar resultados de .NET con resultados de otros lenguajes.
Los sistemas de integración continua leen los formatos TRX y JUnit en las vistas de resultados, mientras que HTML y CTRF aparecen como archivos que se pueden descargar o utilizar en paneles. En Azure DevOps, la opción --report-azdo-upload-artifacts files permite cargar automáticamente los archivos de evidencias de resultados. También se deben nombrar los archivos mediante la opción --report-<format>-filename y marcadores de posición como {asm} y {tfm}, para que los resultados no entren en conflicto en proyectos dirigidos a varios marcos de ejecución.
Haz que las salidas sean estables y automatizables
La opción --list-tests json proporciona un documento con una versión de esquema que describe las pruebas descubiertas y sus ubicaciones de origen. Esto constituye una entrada estable para seleccionar pruebas, analizar el impacto de los cambios e integrar entornos de desarrollo, en lugar de analizar el texto de la consola, que puede cambiar entre versiones.
Las salidas de MTP se adaptan a los entornos de agentes y a los modelos lingüísticos: ocultan el banner informativo, los caracteres ANSI y la animación de progreso, y muestran de forma predeterminada las salidas stdout y stderr solo de las pruebas fallidas. El comportamiento se puede controlar mediante NO_COLOR y las opciones --ansi y --progress.
Fija la política de informes y comprueba la compatibilidad
El artículo recomienda probar MTP 2.3 o una versión posterior en un solo proyecto de pruebas y, después, activar --report-gh en GitHub Actions o --report-azdo en Azure DevOps. Una vez elegida la política, la configuración se guarda en el archivo testconfig.json dentro del repositorio, de modo que las ejecuciones locales y las ejecuciones de CI produzcan los mismos informes. También se puede utilizar Directory.Build.props para aplicar una configuración unificada a todos los proyectos de pruebas, o utilizar el perfil AllMicrosoft para activar el conjunto estable de extensiones, mientras que JUnit y CTRF siguen siendo opcionales.
Los equipos que no utilizan MSTest.Sdk deben comprobar que las versiones de los paquetes de los informadores coincidan con la versión de MTP a la que apunta el marco de pruebas. La compatibilidad con MTP 2.x llega hasta MSTest.TestAdapter 4.0.0, NUnit3TestAdapter 6.0.1, TUnit 1.7.16, YoloDev.Expecto.TestSdk 0.16.0 y las versiones preliminares de xunit.v3 4.0. Además, la solución no admite mezclar proyectos de MTP y VSTest, por lo que la participación en la ejecución de MTP debe configurarse a nivel del repositorio.
Las opciones de historial de Azure DevOps requieren el token SYSTEM_ACCESSTOKEN: $(System.AccessToken). Sin él, la ejecución continúa, pero omite los comentarios históricos. En las canalizaciones actuales se pueden sustituir las tareas de publicación de resultados de pruebas y de publicación de archivos por las opciones correspondientes de MTP, pero la publicación de la cobertura de código no se sustituye; por ello se debe mantener PublishCodeCoverageResults@2. Tampoco se debe activar la publicación directa junto con PublishTestResults@2, porque esto crea dos ejecuciones de prueba separadas para la misma compilación.