Solución de problemas de Microsoft.Testing.Platform (MTP)

Este artículo contiene instrucciones de solución de problemas para MTP.

Códigos de salida

MTP usa códigos de salida conocidos para comunicar errores de prueba o errores de aplicación. Los códigos de salida comienzan en 0 y no son negativos.

Código de salida	Detalles
0	El 0 código de salida indica que se ha realizado correctamente. Todas las pruebas elegidas para ejecutarse se ejecutaron hasta la finalización y no hubo errores.
1	El código de salida 1 indica errores desconocidos y actúa como catch all. Para buscar información adicional sobre errores y detalles, busque en la salida.
2	Se usa un código de salida de 2 para indicar que hubo al menos un error de prueba.
3	El código 3 de salida indica que se anuló la sesión de prueba. Se puede anular una sesión mediante Ctrl+C, como ejemplo.
4	El código 4 de salida indica que la configuración de las extensiones usadas no es válida y que la sesión de pruebas no se puede ejecutar.
5	El código 5 de salida indica que los argumentos de la línea de comandos pasados a la aplicación de prueba no eran válidos.
6 (ya no se usa)	El código 6 de salida ya no lo genera la plataforma; anteriormente indicó que la sesión de prueba usaba una característica no implementada.
7	El código 7 de salida indica que una sesión de prueba no se pudo completar correctamente y probablemente se bloqueó. Es posible que esto se deba a una sesión de prueba que se ejecutó a través del punto de extensión de un controlador de pruebas.
8	El código de salida 8 indica que la sesión de pruebas no encontró ninguna prueba o que se omitió cada una de las pruebas seleccionadas con la opción estricta --zero-tests-policy.
9	El código 9 de salida indica que la ejecución ejecutó menos pruebas que un valor explícito --minimum-expected-tests requiere, incluidas cero pruebas.
10	El código 10 de salida indica que el adaptador de prueba, Testing.Platform Test Framework, MSTest, NUnit o xUnit, no pudo ejecutar pruebas por un motivo de infraestructura no relacionado con la propia prueba. Un ejemplo no puede crear un accesorio necesario para las pruebas.
11	El código 11 de salida indica que el proceso de prueba se cerrará si se cierra el proceso dependiente.
12	El código 12 de salida indica que la sesión de prueba no se pudo ejecutar porque el cliente no admite ninguna de las versiones de protocolo admitidas.
13	El código 13 de salida indica que la sesión de prueba se detuvo debido a que se alcanzó el número especificado de pruebas con error máxima mediante --maximum-failed-tests la opción de línea de comandos. Para obtener más información, consulte la sección Opciones de la referencia de opciones de la CLI de MTP.
14	El código 14 de salida indica que un recopilador de cobertura compatible publicó una evaluación de umbral de cobertura con error.

Un valor explícito --minimum-expected-tests reemplaza --zero-tests-policya . Sin la opción mínima, el control estricto de pruebas cero sigue usando el código 8de salida . Los códigos de salida 8 y 9 siguen siendo distintos para que el incumplimiento de un mínimo no se confunda con un módulo que no ejecutó ninguna prueba.

Para habilitar el registro detallado y solucionar problemas, consulte Registro de diagnóstico.

Cero pruebas en una ejecución de varios módulos

Cuando dotnet test ejecuta varios módulos de prueba, el código de salida 8 es una señal para cada módulo, mientras que el veredicto de cero pruebas de toda la ejecución se determina una sola vez a partir de los resultados agregados. Por lo tanto, un único módulo vacío no produce un error en toda la ejecución, aunque el módulo mantiene su Exit code: 8 diagnóstico en la salida. Cuando no se establece un mínimo global, una ejecución completa omitida se trata como una ejecución de prueba cero independientemente del valor por módulo --zero-tests-policy . Para obtener más información, consulte Los mínimos de ejecución completa y por módulo.

Nota:

Este veredicto de pruebas cero de ejecución completa requiere el SDK de .NET 11 o una versión posterior.

Omitir códigos de salida específicos

MTP está diseñado para ser estricto de forma predeterminada, pero permite la configuración. Por lo tanto, es posible para los usuarios decidir qué códigos de salida se deben omitir (se devolverá un código de salida de 0 en lugar del código de salida original).

Para omitir códigos de salida específicos, use la --ignore-exit-code opción de línea de comandos o la variable de TESTINGPLATFORM_EXITCODE_IGNORE entorno. El formato válido aceptado es una lista separada por punto y coma de códigos de salida que se omitirán (por ejemplo, --ignore-exit-code 2;3;8). Un escenario común es tener en cuenta que los errores de prueba no deben dar lugar a un código de salida distinto de cero (que corresponde a omitir el código 2de salida ).

Registro de diagnóstico

La plataforma proporciona registro de diagnóstico integrado para ayudarle a solucionar problemas de ejecución de pruebas. Puede habilitar el registro de diagnóstico mediante opciones de línea de comandos o variables de entorno.

Opciones de la línea de comandos

Las siguientes opciones de plataforma proporcionan información útil para solucionar problemas de las aplicaciones de prueba:

• --info
• --diagnostic
• --diagnostic-synchronous-write
• --diagnostic-verbosity
• --diagnostic-file-prefix
• --diagnostic-output-directory

Variables de entorno

También puede habilitar los registros de diagnóstico mediante las variables de entorno:

Nombre de la variable de entorno	Description
TESTINGPLATFORM_DIAGNOSTIC	Si se establece en 1, habilita el registro de diagnóstico.
TESTINGPLATFORM_DIAGNOSTIC_VERBOSITY	Define el nivel de verbosidad. Los valores disponibles son Trace, Debug, Information, Warning, Erroro Critical.
TESTINGPLATFORM_DIAGNOSTIC_OUTPUT_DIRECTORY	Directorio de salida del registro de diagnóstico, si no se especifica que el archivo se genere en el directorio predeterminado TestResults.
TESTINGPLATFORM_DIAGNOSTIC_FILE_PREFIX	Prefijo del nombre del archivo de registro. El valor predeterminado genera <asm>_<tfm>_<arch>_<timestamp>.diag. Disponible en MTP a partir de la versión 2.3.0; el nombre heredado TESTINGPLATFORM_DIAGNOSTIC_OUTPUT_FILEPREFIX sigue siendo válido por motivos de compatibilidad con versiones anteriores.
TESTINGPLATFORM_DIAGNOSTIC_SYNCHRONOUS_WRITE	Obliga al registrador de archivos integrado a escribir registros de forma sincrónica. Resulta útil para escenarios en los que no desea perder ninguna entrada de registro (si el proceso se bloquea). Esto ralentiza la ejecución de la prueba. Disponible en MTP a partir de la versión 2.3.0; el nombre heredado TESTINGPLATFORM_DIAGNOSTIC_FILELOGGER_SYNCHRONOUSWRITE sigue siendo válido por motivos de compatibilidad con versiones anteriores.

Nota:

Las variables de entorno tienen prioridad sobre los argumentos de la línea de comandos.

MTP escribe un archivo de diagnóstico para cada origen de prueba. Si dos archivos reciben la misma marca de tiempo, MTP agrega un sufijo de proceso y contador en lugar de sobrescribir un archivo existente.

Resolución de errores de configuración

Microsoft.Testing.Platform.MSBuild

A continuación se muestran errores de configuración comunes relacionados con Microsoft.Testing.Platform.MSBuild.

error CS8892: No se usará el método 'TestingPlatformEntryPoint.Main(string[])' como punto de entrada porque se encontró un punto de entrada sincrónico 'Program.Main(string[])'

Definir manualmente un punto de entrada (Main) en un proyecto de prueba o hacer referencia a un proyecto de prueba desde una aplicación que ya tiene un punto de entrada produce un conflicto con el punto de entrada generado por MTP. Para evitar este problema, siga uno de estos pasos:

• Quite su punto de entrada definido manualmente, que es típicamente el método Main en Program.cs, y permita que la plataforma de prueba genere uno automáticamente para usted.

• Deshabilite la generación del punto de entrada estableciendo la propiedad <GenerateTestingPlatformEntryPoint>false</GenerateTestingPlatformEntryPoint> MSBuild.

• Deshabilite completamente la dependencia transitiva para Microsoft.Testing.Platform.MSBuild estableciendo la propiedad <IsTestingPlatformApplication>false</IsTestingPlatformApplication> MSBuild en el proyecto que hace referencia a un proyecto de prueba. Esto es necesario cuando se hace referencia a un proyecto de prueba desde un proyecto que no es de prueba, por ejemplo, una aplicación de consola que hace referencia a una aplicación de prueba.

El espacio de nombres de código generado entra en conflicto con un tipo al que se hace referencia

Microsoft.Testing.Platform.MSBuild genera los tipos SelfRegisteredExtensions y TestingPlatformEntryPoint dentro de la $(RootNamespace) del proyecto. De forma predeterminada, RootNamespace se corresponde con el nombre del proyecto, lo que puede entrar en conflicto con un tipo con el mismo nombre completo expuesto por un ensamblado referenciado.

Por ejemplo, un proyecto denominado System.Security.Cryptography.ProtectedData.Tests termina generando código en el System.Security.Cryptography.ProtectedData espacio de nombres . Si el proyecto también hace referencia al System.Security.Cryptography.ProtectedData paquete NuGet, que contiene un tipo público ProtectedData en el System.Security.Cryptography espacio de nombres, el compilador ya no puede desambiguar entre el espacio de nombres generado y el tipo al que se hace referencia, y emite errores como CS0118 ("ProtectedData" es un espacio de nombres, pero se usa como un tipo).

Para resolver el conflicto, sobrescriba RootNamespace en su proyecto de prueba con un valor que no entre en conflicto con ningún tipo al que se haga referencia:

<PropertyGroup>
  <RootNamespace>System.Security.Cryptography.ProtectedDataTests</RootNamespace>
</PropertyGroup>

También puede borrar RootNamespace completamente (<RootNamespace />), en cuyo caso los tipos generados se emiten en el espacio de nombres global.

Microsoft.Testing.Extensions.Fakes

Error de Fakes: No se pudo resolver la ruta de acceso del perfilador desde las variables de entorno COR_PROFILER_PATH y COR_PROFILER

Este error puede producirse si no todos los ensamblados de Fakes están presentes en la carpeta bin.

• Asegúrese de que el proyecto use MSTest.SDK o haga referencia a Microsoft.Testing.Extensions.Fakes.
• En el caso de los proyectos de .NET Framework, evite establecer <PlatformTarget>AnyCPU</PlatformTarget>, ya que esto da como resultado que NuGet no copie todos los archivos en la carpeta bin.

Opción de línea de comandos de extensión no reconocida

Una opción de línea de comandos específica de la extensión puede producir un error con el código de salida 5 cuando una aplicación de prueba no registra el paquete que proporciona la opción . Por ejemplo, --report-trx requiere Microsoft.Testing.Extensions.TrxReport, ya sea como referencia de paquete directo o a través de una configuración o perfil de SDK de prueba que incluya el paquete. El núcleo de MTP no incluye opciones de informe, cobertura de código, volcado, reintento ni otras opciones de extensión.

Ejecute la aplicación de prueba con --helpo ejecute dotnet test --help en modo MTP para confirmar que la opción está disponible. Si falta la opción, agregue su paquete de extensión o habilite la extensión a través del SDK de prueba. Consulte Opciones de extensión por escenario para encontrar el paquete necesario.

El mismo error se produce cuando una solución contiene proyectos que usan marcos de pruebas diferentes (por ejemplo, MSTest y xUnit.net) o conjuntos diferentes de extensiones (por ejemplo, solo algunos proyectos hacen referencia Microsoft.Testing.Extensions.HangDumpa ). La opción es válida para un proyecto pero no reconocido por otro.

Para resolver este problema, use la TestingPlatformCommandLineArguments propiedad MSBuild con condiciones para enrutar argumentos a los proyectos correctos. Para obtener instrucciones detalladas, consulte Soluciones con marcos de pruebas mixtas o extensiones.