A principios de este año, anunciamos que todos los principales frameworks de pruebas de .NET ahora son compatibles con Microsoft.Testing.Platform. El siguiente paso lógico era asegurar su integración perfecta con las pipelines de CI/CD. Hoy, nos complace anunciar una integración completa de Microsoft.Testing.Platform en Azure DevOps, llevando la experiencia de prueba en .NET a un nuevo nivel de eficiencia y fiabilidad.
Novedades en Azure DevOps para Microsoft.Testing.Platform
Azure DevOps ofrece ahora un soporte de primera clase para Microsoft.Testing.Platform, destacando dos mejoras clave que simplifican enormemente el flujo de trabajo de pruebas:
- Ejecución de pruebas simplificada: Ahora puedes ejecutar tus pruebas utilizando la familiar tarea
DotNetCoreCLI, eliminando la necesidad de soluciones alternativas complejas. Esto proporciona una experiencia de ejecución de pruebas mucho más directa y coherente. - Gestión inteligente de reintentos de pruebas: La plataforma ahora maneja los reintentos de pruebas de forma nativa. Esto significa que los archivos TRX generados por múltiples intentos de reintento se publican correctamente, agrupando los resultados y estableciendo los códigos de salida apropiados. Esta funcionalidad es crucial para gestionar pruebas intermitentes («flaky tests») sin generar errores falsos en la pipeline.
Tanto si estás migrando desde VSTest como si empiezas de cero con Microsoft.Testing.Platform, la experiencia ahora es fluida e intuitiva desde el primer momento.
¿Qué es Microsoft.Testing.Platform?
Para aquellos que aún no están familiarizados, Microsoft.Testing.Platform es una alternativa moderna y robusta a VSTest. Es una plataforma de pruebas diseñada para el ecosistema .NET, que proporciona un entorno potente y flexible para la ejecución de pruebas unitarias y de integración. Si deseas profundizar, aquí tienes algunos recursos esenciales:
- Pruebas en .NET: Una visión general de las herramientas de pruebas en .NET, aclarando la diferencia entre una plataforma de pruebas y un framework de pruebas.
- Pruebas con ‘dotnet test’: Explica los diferentes modos de operación del comando
dotnet test. - Introducción a Microsoft.Testing.Platform: Cubre qué es la plataforma y cómo ejecutar pruebas con ella.
- Mejora tu flujo de trabajo de pruebas CLI con el nuevo dotnet test: Muestra el soporte de
dotnet testpara Microsoft.Testing.Platform añadido en el SDK de .NET 10.
Ejecutando Pruebas en Azure DevOps
La tarea DotNetCoreCLI ahora soporta Microsoft.Testing.Platform a partir de la versión 2.263.0. Tienes dos opciones principales para ejecutar tus pruebas:
Opción 1: Usar la tarea DotNetCoreCLI (Recomendado)
Esta es la opción preferida por su simplicidad y alineación con las prácticas de Azure DevOps. La tarea DotNetCoreCLI de Azure DevOps ha sido actualizada para soportar Microsoft.Testing.Platform.
- task: DotNetCoreCLI@2
displayName: 'Run tests'
inputs:
command: 'test'
projects: '**/*Tests.csproj'
arguments: '--no-build --report-trx'
¿Qué ha cambiado? Microsoft.Testing.Platform utiliza diferentes flags de línea de comandos en comparación con VSTest. Por ejemplo, se usa --report-trx en lugar de --logger trx. Consulta la documentación CLI de Microsoft.Testing.Platform para una lista completa de opciones.
Opción 2: Ejecutar ‘dotnet test’ directamente
Si necesitas una mayor flexibilidad o control sobre la ejecución de las pruebas, puedes invocar el comando dotnet test directamente utilizando una tarea de script o línea de comandos. Esto evita dependencias de versiones específicas de tareas de Azure DevOps.
- task: CmdLine@2
displayName: 'Run tests'
inputs:
script: 'dotnet test --no-build --report-trx'
¿Cuándo usar esta opción? Es ideal si requieres scripting personalizado alrededor de la ejecución de pruebas o si prefieres no depender de las actualizaciones de tareas específicas.
Migración desde la tarea VSTest
Es importante destacar que la tarea VSTest de Azure DevOps fue diseñada exclusivamente para VSTest y no soportará Microsoft.Testing.Platform. Si actualmente utilizas esta tarea, los pasos para migrar son sencillos:
- Cambia a la Opción 1 (tarea DotNetCoreCLI) para una experiencia más similar y recomendada.
- Actualiza tus argumentos de línea de comandos para usar la sintaxis específica de Microsoft.Testing.Platform (por ejemplo,
--report-trx). - Prueba tu pipeline para asegurar que el descubrimiento y la ejecución de pruebas funcionan como esperas.
Ambas opciones, DotNetCoreCLI y CmdLine, proporcionan las mismas capacidades de ejecución de pruebas que la tarea VSTest, pero con el soporte moderno de Microsoft.Testing.Platform.
Publicación de Resultados de Pruebas con Soporte para Reintentos
El desafío principal al usar la extensión de Reintentos de Microsoft.Testing.Platform era que generaba un archivo TRX separado para cada intento de reejecución de una prueba fallida. La tarea PublishTestResults solía interpretar estos como ejecuciones de pruebas independientes, llevando a dos problemas:
- Códigos de salida incorrectos: La tarea podía fallar incluso si las pruebas pasaban eventualmente después de un reintento.
- Interfaz de usuario confusa: Los resultados de las pruebas aparecían como ejecuciones separadas en lugar de agruparse como intentos de reintento de la misma prueba.
¡Hemos resuelto esto! La tarea PublishTestResults ahora maneja inteligentemente múltiples archivos TRX de intentos de reintento, agrupándolos correctamente y estableciendo los códigos de salida adecuados. Esto proporciona una visión clara y precisa del estado de tus pruebas, especialmente aquellas que son intermitentes.
Configuración Necesaria
Para habilitar la publicación de resultados de pruebas con reconocimiento de reintentos, debes establecer la variable AllowPtrToDetectTestRunRetryFiles en true en tu pipeline. Esta flag opt-in activa el nuevo comportamiento que interpreta correctamente múltiples archivos TRX como intentos de reintento en lugar de ejecuciones separadas. Es crucial que esta variable se configure a nivel de pipeline (en tu archivo YAML o variables de pipeline), ya que no funcionará si se establece a nivel de proyecto u organización.
Ejemplo Completo de Pipeline
Aquí tienes un ejemplo completo de una pipeline que demuestra la ejecución de pruebas con reintentos y la publicación adecuada de los resultados:
trigger:
- main
jobs:
- job: MyJob
variables:
AllowPtrToDetectTestRunRetryFiles: true
steps:
# Pasos habituales para instalar .NET SDK, restaurar y compilar.
- task: CmdLine@2
displayName: 'Run tests'
inputs:
script: 'dotnet test --no-build --report-trx --retry-failed-tests 3 --results-directory TestResults'
- task: PublishTestResults@2
displayName: 'Publish test results'
inputs:
testResultsFormat: 'VSTest'
testResultsFiles: '**/*.trx'
mergeTestResults: true
failTaskOnFailedTests: true
condition: succeededOrFailed()
Puntos clave en esta pipeline:
- La variable
AllowPtrToDetectTestRunRetryFiles: truehabilita el comportamiento de reconocimiento de reintentos. - El flag
--retry-failed-tests 3indica a la plataforma de pruebas que reintente las pruebas fallidas hasta 3 veces. - La condición
condition: succeededOrFailed()asegura que los resultados de las pruebas se publiquen incluso si algunas pruebas fallan, permitiendo una visibilidad completa.
Comprendiendo los Resultados de los Reintentos en la UI de Azure DevOps
La interfaz de usuario de Azure DevOps ahora muestra de forma clara los resultados en diferentes escenarios de reintentos. Consideremos un escenario con una prueba estable que siempre pasa y una prueba «flaky» con fallos intermitentes:
Escenario 1: Todas las pruebas pasan en el primer intento
Los indicadores de éxito estándar se muestran y la tarea PublishTestResults se completa satisfactoriamente. Todo funciona como se espera, sin complicaciones.

Escenario 2: La prueba pasa después de reintentos
Aquí es donde la nueva funcionalidad brilla. La UI muestra que una prueba falló en los intentos 1 y 2, pero tuvo éxito en el intento 3. A pesar de los fallos iniciales, la tarea PublishTestResults pasa porque la prueba finalmente tuvo éxito. Este es el comportamiento correcto para manejar pruebas «flaky», ya que no detendrá la pipeline innecesariamente.

Escenario 3: La prueba falla en todos los intentos de reintento
Cuando una prueba falla en todos sus intentos de reintento, la UI agrupa todos los fallos para una revisión fácil. Puedes examinar cada fallo individual para identificar patrones o diferencias. La tarea PublishTestResults fallará como se espera si failTaskOnFailedTests está configurado en true, indicando un problema real que requiere atención.

Por qué es Importante
La distinción entre VSTest y Microsoft.Testing.Platform es crucial aquí: VSTest nunca tuvo soporte nativo para reintentos. Con la extensión de Reintentos de Microsoft.Testing.Platform, obtienes un manejo automático de reintentos con una integración adecuada en Azure DevOps, sin necesidad de scripting personalizado.
¡Empieza Hoy Mismo!
Azure DevOps ahora ofrece un soporte completo para Microsoft.Testing.Platform, desde la ejecución de pruebas hasta la publicación de resultados de reintentos con un manejo inteligente. Si estás listo para aprovechar estas mejoras:
- Actualiza a .NET SDK 10 (o superior).
- Añade la extensión Retry a tu proyecto de pruebas.
- Configura
AllowPtrToDetectTestRunRetryFiles: trueen tu pipeline YAML. - Ejecuta tus pruebas con el flag
--retry-failed-testspara activar la funcionalidad de reintentos.
¿Necesitas ayuda o tienes preguntas? Estamos aquí para ti:
- Preguntas: Discusiones en GitHub
- Reportar problemas: Incidencias en GitHub
- Más información: Documentación de Microsoft.Testing.Platform
