¿Por qué el Test Runner de Visual Studio 2015/2017 no descubre mis pruebas xUnit v2?

ACTUALIZACIÓN: Agregar un 2017; VS2017 usa el mismo mecanismo de descubrimiento de prueba / integración de corredor que 2015, por lo que las cosas clave que pueden salir mal son las mismas.


He leído por qué el corredor xUnit no encuentra mis pruebas, lo que explica las razones por las que xUnit nunca podría encontrar las pruebas, pero mi problema es diferente: estoy seguro de que no pasa nada sutil con mis pruebas; (han funcionado en otros entornos, parece ser solo mi máquina): el Visual Studio Test Runner en Visual Studio 2015 [Community Edition] simplemente no muestra ninguna de mis pruebas. No estoy haciendo nada remotamente emocionante; las pruebas se dirigen a xUnit.net v2 en el escritorio.

He buscado en la ventana de resultados y no veo nada en absoluto en Probar en la presentación de las tabs.

  1. Eliminar las excepciones de descubrimiento de sus consultas; vaya a la ventana de salida (Ctrl-Alt-O), luego cambie la salida del show de la lista desplegable (Shift-Alt-S) a Pruebas y asegúrese de que no haya excepciones de descubrimiento

  2. Como se sugiere en esta respuesta (mejor si la técnica ayuda), ejecutar el corredor de la consola de escritorio ( instrucciones ) puede ser una buena verificación cruzada para eliminar otras posibilidades, por ejemplo, archivos de configuración dañados: –

    packages\xunit.runner.console.2.2.0\tools\xunit.console

  3. Prueba | Configuración de prueba | La architecture de procesador predeterminada puede ayudar si las pruebas son específicas de x86 / x64 y el descubrimiento está desencadenando excepciones relacionadas con la trituración, es decir, no AnyCpu


Ve a leer la documentación , es completa, actualizada, incluye información de resolución de problemas y toma PRs:

Nota importante: si instaló previamente xUnit.net Visual Studio Runner VSIX (Extensión), primero debe desinstalarlo. El corredor de Visual Studio solo se distribuye a través de NuGet ahora. Para eliminarlo, vaya a Herramientas > Extensiones y actualizaciones . Desplácese hasta el final de la lista y, si xUnit.net está instalado, desinstálelo. Esto te obligará a reiniciar Visual Studio.

Si tiene problemas para descubrir o ejecutar pruebas, puede ser víctima de un caché de corredor corrupto dentro de Visual Studio. Para borrar este caché, cierre todas las instancias de Visual Studio y luego elimine la carpeta %TEMP%\VisualStudioTestExplorerExtensions . También asegúrese de que su proyecto esté vinculado a una sola versión del paquete NuGet del corredor de Visual Studio ( xunit.runner.visualstudio ).

Los siguientes pasos me funcionaron:

  1. (Solo si sospecha que hay un problema grave en su máquina, en general, el caso más común es que la integración visual studio simplemente no está instalada aún)

    Realice el DEL %TEMP%\VisualStudioTestExplorerExtensions según lo recomendado: –

    PS> del $env:TEMP\VisualStudioTestExplorerExtensions

  2. Instale el paquete xunit.runner.visualstudio en todos los proyectos de prueba

    • Paket:

       .paket\paket add nuget xunit.runner.visualstudio -i 

      paket.dependencies terminar con lo siguiente en su paket.dependencies :

      nuget xunit.runner.visualstudio version_in_path: true

      Tenga en cuenta el version_in_path: true bit version_in_path: true es importante

    • Nuget: vaya a la consola del administrador de paquetes (Alt-T, N, O) y

       Install-Package xunit.runner.visualstudio) 

    Reconstruya para asegurarse de que xunit.runner termine en el directorio de salida

  3. Cerrar Test Explorer <- esto fue lo que faltaba para mí

  4. Vuelva a abrir Test Explorer (Alt-S, W, T)

  5. Ejecutar todas las pruebas (Ctrl R, A)

Ninguna de las soluciones anteriores funcionó para mí (dotnetcore 1.1, VS2017). Esto es lo que lo solucionó:

  1. Agregue el paquete NuGet “Microsoft.TestPlatform.TestHost”
  2. Agregue el paquete NuGet “Microsoft.NET.Test.Sdk”

Esos son adicionales a estos paquetes que instalé antes:

  • xunit (2.3.0-beta1-build3642)
  • xunit.runner.visualstudio (2.3.0-beta1-build1309)

Tuve que cambiar la configuración de prueba después de cambiar la CPU de los proyectos de prueba a x64. Luego las pruebas se detectaron de nuevo.

Arquitectura

Sigue estos pasos:

  1. Actualice los MsTest.TestAdapter dll's MsTest.TestAdapter y MsTest.TestFramework dll's nugget package manager .
  2. Limpia tu solución
  3. Construye tu solución.

Instalar el paquete xunit.runner.visualstudio para el proyecto de prueba

He estado luchando con esto toda la tarde mientras trabajaba con un proyecto ASP Core y xUnit 2.2.0. La solución para mí fue agregar una referencia a Microsoft.DotNet.InternalAbstractions

Descubrí esto cuando traté de ejecutar el proyecto de prueba manualmente con la dotnet test que falló pero informaba que faltaba InternalAbstractions . No vi este error en la ventana de resultados de prueba cuando falló el descubrimiento automático. La única información que vi en la ventana de descubrimiento fue un código de retorno, que no significaba nada para mí en ese momento, pero en retrospectiva probablemente indicaba un error.

Me ha sucedido un par de veces: cuando limpio el proyecto y lo vuelvo a armar, suele estar bien.

Después de pasar 2 días … nada de lo anterior funcionó para mí. La única “solución” era: ir a las propiedades del proyecto -> pestaña de comstackción. Luego haga clic en el botón Avanzado en la esquina inferior derecha del panel. Cambie “Información de depuración:” a “completo” y haga clic en Aceptar.

Aquí están las capturas de pantalla: enter image description here

enter image description here enter image description here

Estoy usando xUnit 2.2.0.

Mi problema era que mi solución no podía encontrar ciertos dlls y app.config estaba tratando de resolverlos. El error no aparecía en la ventana de resultados de prueba en Visual Studio.

Pude identificar el error cuando instalé xunit.runner.console y traté de ejecutar las pruebas a través de la línea de comandos.

Cómo ejecutar pruebas de xunit en CLI .

Esto también puede deberse a que la checkbox de comstackción no está marcada para el proyecto de plataforma actual en la configuración de comstackción. Haga clic en Construir | Administrador de configuración, luego asegúrese de que los proyectos de prueba tengan un tic en la columna de construcción para la plataforma que está usando (por ejemplo, ‘x86’).

Esta fue definitivamente la solución que funcionó para mí.

Asegúrese de no haber escrito las pruebas de su unidad en una biblioteca de clases .NET estándar 2.0. El visualstudio runner no admite la ejecución de pruebas en las bibliotecas de clases netstandard2.0 en el momento de escribir este artículo.

Consulte aquí la matriz de Compatibilidad de Test Runner:

https://xunit.github.io/#runners

El motivo en mi caso fue que la comstackción de destino no era la misma entre el depurador del proyecto y el corredor de prueba. Para unificar esos elementos:

  1. Prueba> Configuración de prueba> Arquitectura predeterminada del procesador. luego seleccione X64 o X86.
  2. Proyecto> (su proyecto) Propiedades> Build (tab)> objective de la plataforma.

Después de que sean idénticos, reconstruya su solución, entonces los métodos de prueba aparecerán para usted.

Puedo ofrecer una solución para un caso extremo con el que me encontré hace unos días. No va a ser la solución que se ajuste a todos los escenarios descritos anteriormente, sin embargo, para el caso límite, lo tuve que arreglar.

Tuve el mismo problema con los más recientes VS 2017 (versión 15.5.7) y XUnit 2.3.1. Se instaló el paquete xunit.runner.visualstudio, sin embargo, las pruebas no aparecieron en el explorador de prueba incorporado de VisualStudio.

Estaba trabajando en un proyecto heredado que tenía como objective .NET Framework 4.5. Sin embargo, comenzando con la versión 2.2. XUnit no es compatible con los frameworks .NET inferiores a 4.5.2 (ver Notas de la versión – XUnit 2.2: 19 de febrero de 2017

Cambiar el marco de destino del proyecto de prueba a una versión> = 4.5.2 funcionó para mí. No tiene que cambiar la versión del proyecto que está probando, solo se trata del proyecto de prueba en sí.

En mi caso, tuve 2 proyectos de prueba diferentes en la solución. Se pudieron encontrar las pruebas del Proyecto 1, pero las pruebas del Proyecto 2 no pudieron. Descubrí que primero descargué el proyecto de prueba 1, luego cerré VS> borrando mis archivos temporales> volví a abrir la solución> reconstruir, permití a VS descubrir mis pruebas del Proyecto 2.

Supongo que algo debe estar en conflicto entre los dos proyectos de prueba y esta fue la forma más rápida de ponerme en funcionamiento en unos minutos. Los problemas se pueden resolver más tarde :).

Se encontró con un problema similar con VS que no descubrió métodos de prueba. En mi caso, tenía la palabra clave estática con el método, que eliminé y funcionó.

 [TestMethod] Before: public static void Test1() After: public void Test1() 

Estuve sufriendo este problema por mucho tiempo.

  • Tenía aproximadamente 100 proyectos. Se implementó una versión diferente en un servidor diferente.

  • La actualización de xunit de 2.2.0 a 2.3.1 no fue una solución porque la comstackción fallaba en 2.3.1.

Luego acabo de actualizar xunit.runner.visualstudio a 2.3.1 y todo comenzó a funcionar bien. He utilizado este comando en mi consola de administrador de paquetes para actualizar mi paquete xunit.runner.visualstudio

 Get-Project ComapanyName.ProjectName.*.Tests | Install-Package xunit.runner.visualstudio -Version 2.3.1 

El culpable más común para mí ha sido Visual Studio tratando de ejecutar las pruebas usando una architecture diferente a la biblioteca que está probando. Lamentablemente, hay varios lugares donde parece que esto puede salir mal.

En VS 2017, intente crear un archivo de configuración de ejecución, por ejemplo, Default.runsettings en su proyecto de prueba. Si su lib principal es x64, el contenido debería ser:

    x64   

A continuación, elija este archivo desde Prueba -> Configuración de prueba -> Seleccionar archivo de configuración de prueba.

Luego, en Prueba -> Configuración de prueba, Arquitectura de procesador predeterminada, elija nuevamente la architecture correcta.

Asegúrese de limpiar y construir toda la solución. Es posible que deba cerrar y volver a abrir la ventana del Explorador de pruebas. Busque cualquier error adicional en la ventana Salida -> Prueba para obtener más pistas sobre tipos de architecture incorrectos.

Aquí se encuentran entradas de configuración de prueba adicionales.

Existe otro motivo que puede hacer que Test Explorer no muestre ninguna prueba, y tiene que ver con el nuevo formato de archivo .pdb portátil presentado con Visual Studio 2017 / para .NET Core que puede romper algunas herramientas VS. (Antecedentes: consulte el informe de error “Mono.Cecil causa OutOfMemoryException con nuevos .csproj PDB” ).

¿No se encuentran sus pruebas debido al nuevo .pdb portable .pdb (símbolos de depuración)?

  • Abra la ventana de Salida .
  • Cambiar la selección desplegable para Mostrar salida desde a Pruebas .
  • Si ve resultados como los siguientes (posiblemente repetidos una vez para cada una de sus pruebas), entonces tiene el problema descrito en esta respuesta:

     Exception System.OutOfMemoryException, Exception converting  Array dimensions exceeded supported range. 

Si es así, haga esto para resolver el problema:

  • Abra las propiedades de su proyecto de prueba (seleccione el proyecto de prueba en el Explorador de soluciones y presione Alt + Intro ).
  • Cambia a la pestaña Construir .
  • Haga clic en el botón Avanzado … (ubicado al final de esa pestaña).
  • En la lista desplegable etiquetada como información de depuración , seleccione none , pdb-only o full , pero NOT portable . Es esta última configuración la que hace que las pruebas no se encuentren.
  • Haga clic en Aceptar y limpie y reconstruya su proyecto. Si desea estar más seguro, vaya al directorio de salida de su proyecto de prueba y limpie todos los archivos .pdb antes de reconstruir. Ahora tus pruebas deberían estar de vuelta.

Me sucedió cuando hice mi primer bash de caminar con IntelliTest en VS 2017.

A veces, cuando el proyecto de prueba se crea automáticamente por IntelliTest, la referencia de ensamblado de Microsoft.ExtendedReflection ( … \ Archivos de progtwig (x86) \ Microsoft Visual Studio \ 2017 \ Enterprise \ Common7 \ IDE \ Extensions \ Microsoft \ Pex \ Microsoft .ExtendedReflection.dll ) no se encuentra. Cuando se agrega, las pruebas generadas aparecerán en el explorador de prueba después de la recomstackción.

Descargo de responsabilidad: no se trata de xunit con visual studio 2015, sino de Visual Studio 2017 con una aplicación de prueba de unidad UWP (MSTest). Llegué a este hilo buscando lo mismo así que tal vez alguien más haga lo mismo 🙂

La solución para mí fue actualizar los paquetes nuget para MSTest.TestAdapter y MSTest.TestFramework. Parece que cuando creas una aplicación de prueba unitaria para UWP no obtienes automáticamente las últimas versiones.

En mi caso, tengo varios proyectos de prueba en la misma solución, y solo uno de los proyectos no mostraba el “Explorador de prueba”.

Fui al “paquete de gestión de Nuget para la solución” haciendo clic derecho en la solución.

Noté que en la pestaña “Consolidar” había algunos paquetes nuget “Test” que no estaban sincronizados entre los proyectos. Hice clic en “Instalar” y aparecieron las pruebas que faltaban.

También verifique si hay un archivo app.config completamente vacío (completamente vacío y sin marcas) dentro del proyecto de prueba. Este fue el culpable en mi caso.

En mi caso, creé una nueva “Configuración de la solución” como se muestra en la imagen. Así que cuando selecciono mi personalizado como “Prod”, no reconoce TestMehods por algún motivo. Volver a “Depurar” resuelve el problema

enter image description here

No sé si algunos de ustedes también usan JustMock, pero tuve que desactivar el generador de perfiles en VS 2017 para que funcione la detección de prueba.

Mi problema se resolvió instalando el nuget xunit.runner.visualstudio

Tenía muchos proyectos de diferentes tipos en mi solución y no podía ejecutar el proyecto de prueba Xunit. Los descargué todos excepto mi proyecto Xunit y luego reconstruí la solución que aparecía en Visual Studio y pude ejecutarlos.

Debe actualizar todos sus paquetes cuando se mueva VS2015 a VS2017 para descubrir la prueba en el explorador de prueba.

I Clear Temp,% Temp% y Prefetch. Luego intenté reabrir VS y pude encontrar los métodos de prueba

Tengo el proyecto de prueba A y B. Las pruebas en el Proyecto A se descubrieron, pero el Discovery nunca se detuvo para B. Tuve que matar manualmente a TestHost para detenerme.

Hice muchas cosas que esta página describe incluso al punto de que no estoy seguro de si esta era la solución.

Ahora funcionó y lo que hice fue abrir la Solución y NO tener el Test Explorer arriba. En su lugar, solo revisé la ventana de Resultados para Pruebas y pude ver que el proceso de descubrimiento finalizaba y el número de pruebas era igual a A + B. Después de esto, abrí el Test Explorer y luego A y B estaban presentes. Asi que:

Desinstale e instale las últimas novedades de xUnit correctamente. Elimine el% temp% como se menciona anteriormente, agregue el paquete NuGet “Microsoft.TestPlatform.TestHost” Agregue el paquete NuGet “Microsoft.NET.Test.Sdk”, reinicie pero solo verifique el resultado de las pruebas. Si funciona, verás

Intenté la mayoría de las sugerencias anteriores y nada funcionó. En mi caso, estoy en un equipo y aparecieron pruebas para otros desarrolladores para la misma solución. Entonces, intenté simplemente eliminar mi carpeta .vs, pero tampoco tuve suerte allí.

Terminé borrando por completo mi carpeta local y volviendo a clonar el repository. Eso lo resolvió para mí.