Visual Studio 2015 o 2017 no descubre pruebas unitarias

EDITAR 2016-10-19:

La pregunta original era sobre un problema específico de VS2015 CTP6 con el corredor de prueba XUnit. De las respuestas queda claro que existe un problema mucho más amplio con el descubrimiento de pruebas unitarias en Visual Studio, que puede ocurrir en muchas situaciones diferentes. He limpiado mi pregunta para reflejar eso.

También incluí un guión en mi propia respuesta que aún utilizo para resolver problemas similares cuando aparecen.

Muchas otras respuestas también han demostrado ser útiles para comprender mejor las complejidades del corredor de pruebas VS. ¡Aprecio que la gente todavía esté compartiendo sus soluciones!


Pregunta original 2015-04-10:

Desde ayer, mi Visual Studio Test Explorer no descubrirá pruebas para ninguno de mis proyectos. No muestra la barra de carga verde después de la construcción, tampoco.

Cuando voy al Visual Studio Test Explorer y hago clic en “Ejecutar todo”, o cuando hago clic con el botón secundario en cualquier método de prueba y selecciono “Ejecutar pruebas”, aparece lo siguiente en la ventana de resultados:

Could not load file or assembly 'Microsoft.VisualStudio.Web.ProjectSystem, Version=14.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.

Estoy ejecutando Visual Studio 2015 CTP 6 en la Vista previa técnica de Windows 10 Pro, comstackción 10041. La versión de .NET Framework no parece importar: sucede en 4.0 , 4.5.2 y 4.6 .

Intenté con los siguientes frameworks de prueba y todos dieron el mismo comportamiento:

  • Microsoft.VisualStudio.QualityTools.UnitTestFramework v14.0.22609.0
  • xunit v2.1.0-beta1-build2945 con xunit.runner.visualstudio v2.1.0-beta1-build1051
  • NUnit v2.6.4 con NUnitTestAdapter v2.0.0

Encontré un problema en GitHub (xunit) que parecía ser similar: No se pueden obtener pruebas # 295 descubiertas , con este comentario del equipo de xunit:

Tenga en cuenta que Visual Studio 2015 CTP 5 ha sido informado por muchas personas con pruebas unitarias en general (no solo xUnit.net), así que no espere que funcione.

Además, asegúrese de haber limpiado el caché de corredores de Visual Studio. Si se corrompe, Visual Studio se comportará de forma permanente hasta que se elimine. Para borrar el caché, cierre todas las instancias de Visual Studio y luego elimine la carpeta% TEMP% \ VisualStudioTestExplorerExtensions (honestamente, probablemente no estaría de más eliminar todo en% TEMP% que se puede eliminar).

Intenté su sugerencia para eliminar la carpeta %TEMP%\VisualStudioTestExplorerExtensions . Desafortunadamente eso no solucionó el problema.

Noté que ReSharper en realidad puede descubrir algunas pruebas. Solo funciona para las pruebas VS y NUnit, no para xunit.

Tiene que haber algún tipo de carpeta temporal o de caché que necesito borrar, pero sé que Visual Studio tiene muchos de ellos y no todos pueden eliminarse sin efectos secundarios no deseados.

    Para mi sorpresa, borrar los archivos temporales ubicados en el directorio %TEMP% resolvió el problema para mí.

    Nota: esta ruta generalmente se encuentra en C:\Users\(yourusername)\AppData\Local\Temp

    Como @ Warren-P incluido, puede navegar a la carpeta temporal al poner %temp% en el Menú de Inicio, o abrir “Explorador de Archivos” e ingresar %temp% en la barra de direcciones.

    Podría ser que sus códigos se hayan comstackdo con x64, por lo tanto, tienen que habilitar la Arquitectura de procesador predeterminada como X64.

     Test > Test Settings > Default Processor Architecture > X64 
    • Verifique si NUnit Test Adapter 2/3 está instalado en VisualStudio.
      (Tools>Extensions and Updates )

    • Asegúrese de elegir la architecture de procesador correcta:
      (Test>Test Settings>Default Processor Architecture)

    EDITAR 2016-10-19 (secuencia de comandos de PowerShell)

    Este problema todavía regresa de vez en cuando. Escribí un pequeño fragmento de PowerShell para automatizar la eliminación de la carpeta / archivos temporales de caché / temp para mí. Lo estoy compartiendo aquí para futuros lectores:

     @( "$env:TEMP" "$env:LOCALAPPDATA\Microsoft\UnitTest" "$env:LOCALAPPDATA\Microsoft\VisualStudio\14.0\1033\SpecificFolderCache.xml" "$env:LOCALAPPDATA\Microsoft\VisualStudio\14.0\1033\ProjectTemplateMRU.xml" "$env:LOCALAPPDATA\Microsoft\VisualStudio\14.0\ComponentModelCache" "$env:LOCALAPPDATA\Microsoft\VisualStudio\14.0\Designer\ShadowCache" "$env:LOCALAPPDATA\Microsoft\VisualStudio\14.0\ImageLibrary\cache" "$env:LOCALAPPDATA\Microsoft\VisualStudio Services\6.0\Cache" "$env:LOCALAPPDATA\Microsoft\WebsiteCache" "$env:LOCALAPPDATA\NuGet\Cache" ) |% { Remove-Item -Path $_ -Recurse -Force } 

    Asegúrese de cerrar Visual Studio de antemano y probablemente sea una buena idea reiniciar después.

    La eliminación de la carpeta TEMP puede no ser necesaria y, en algunos casos, incluso puede ser indeseable, por lo que recomendaría intentar sin borrar primero la carpeta TEMP. Simplemente omita el "$env:TEMP" .

    Respuesta original 2015-04-12

    El problema se “resolvió” después de una limpieza exhaustiva de las carpetas de temp / caché relacionadas con Visual Studio.

    Como no tuve tiempo para revisar todo uno por uno y luego hacer una prueba intermedia, desafortunadamente no sé cuál causó el problema.

    Estos son los pasos exactos que he tomado:

    1. Cerrado Visual Studio
    2. CCleaner usado para borrar archivos y carpetas temp sistema y del navegador
    3. Borrado / borrado manualmente los siguientes archivos / carpetas:

      • %USERPROFILE%\AppData\Local\assembly
      • %USERPROFILE%\AppData\Local\Microsoft\UnitTest
      • %USERPROFILE%\AppData\Local\Microsoft\VisualStudio\14.0\1033\SpecificFolderCache.xml
      • %USERPROFILE%\AppData\Local\Microsoft\VisualStudio\14.0\1033\ProjectTemplateMRU.xml
      • %USERPROFILE%\AppData\Local\Microsoft\VisualStudio\14.0\ComponentModelCache
      • %USERPROFILE%\AppData\Local\Microsoft\VisualStudio\14.0\Designer\ShadowCache
      • %USERPROFILE%\AppData\Local\Microsoft\VisualStudio\14.0\ImageLibrary\cache
      • %USERPROFILE%\AppData\Local\Microsoft\VisualStudio Services\6.0\Cache
      • %USERPROFILE%\AppData\Local\Microsoft\WebsiteCache
      • %USERPROFILE%\AppData\Local\NuGet\Cache
      • %USERPROFILE%\AppData\Local\Temp

    Una razón para este problema es que su clase de prueba no es pública. MSTest solo descubre pruebas de clases públicas.

    En Visual Studio 2015 (Actualización 3) si desea adjuntar las pruebas en el explorador de prueba, entonces debe instalar el Adaptador de prueba NUnit. Descargue el adaptador de Herramientas-> Extensión y actualizaciones-> pestaña En línea (debe buscar el adaptador) ) -> Descargar . Al reiniciar Visual Studio, puede ver el cambio para el marco de prueba.

    No tengo una respuesta completa a esto, pero he determinado algunas cosas jugando con un proyecto de prueba:

    1. El xunit.runner.aspnet : 2.0.0-aspnet-beta4 que parece ser parte de la versión oficial beta4 aspnet5 no funciona en Visual Studio.
    2. En cambio, usando "xunit": "2.1.0-*" y "xunit-runner.dnx": "2.1.0-*" SI funcionan en Visual Studio.
    3. Para que VS descubra las pruebas, su proyecto DEBE tener un comando SIMPLE llamado “prueba” que ejecute “xunit.runner.dnx”. Agregar comandos adicionales puede romperlo.
    4. Si su ventana de Test Explorer aún termina vacía, ELIMINE el comando “prueba” de su proyecto, luego vuelva a comstackr la solución y luego vuelva a agregar el comando “prueba” al proyecto.json.
    5. Limpiar todas sus memorias caché según la sugerencia de @ Fred-Kleuver puede ayudar, pero no he hecho todos los pasos en forma aislada, así que no estoy seguro.

    Esto es actual según VS 2015 CTP 6, utilizando las versiones beta4, no los diarios.

    Tuve una instancia en la que algunas pruebas no se recogieron porque las había hecho async la siguiente manera:

    public async void This_IsMy_UnitTest()

    El problema fue que me olvidé de hacerles devolver una Task y no se void cuando hice el cambio. Uno podría pensar que esto causaría un error o una prueba fallida, pero no. Las pruebas unitarias en esa clase fueron completamente ignoradas y actuaron como si no existieran.

    No fue después de aproximadamente 3 clean and builds + restarting VS.NET cuando vi la ejecución de la prueba y fallaba al indicar que olvidé agregar el tipo de devolución de la Task :

    public async Task This_IsMy_UnitTest()

    Después de la actualización, las pruebas unitarias se encontraron y funcionaron correctamente. Esto podría ser un caso extremo, pero tener pruebas async para usar await dentro pero no tener la firma correcta puede causar el mismo problema y no es la primera vez que hago esto.

    Vaya al administrador de paquetes Nuget y descargue Nunit Adapter de la siguiente manera.

    enter image description here

    Tenía el mismo pronombre, pero la carpeta “% TEMP% \ VisualStudioTestExplorerExtensions” no existía en mi máquina, así que al leer las publicaciones tuve la idea de crearla y funciona. El explorador de prueba ahora puede mostrar todas mis pruebas. Gracias.

    La solución en mi caso fue simplemente instalar la extensión NUnit 3 Test Adapter en mi Visual Studio 2015.

    'Extensiones y actualizaciones' está presente en el menú 'Herramientas'

    En mi caso (Visual Studio Enterprise 2015 14.0.25425.01 Actualización 3, Resharper 2016.2) solo necesitaba hacer una solución limpia desde el menú Generar. Al reconstruir la solución, el explorador de prueba se “despierta” y encuentra todas las pruebas nuevamente.

    Simplemente reinicie Visual Studio y en Test Explorer haga “Run All” … Todas mis pruebas se descubren en ese momento.

    En mi caso, el problema era “entre la silla y el teclado”. Cambié a una configuración en Configuration Manager que no incluía mis proyectos de prueba unitarios en build. El cambio a una configuración (por ejemplo, Debug) que incluye todos los proyectos solucionó el problema.

    En mi caso, MSTest bajo VS 2015 estaba ignorando las pruebas con nombres de prueba (es decir, métodos) que tenían más de 174 caracteres. Acortar el nombre permitió que la prueba sea visible. Esto se determinó a través de adivinar y verificar manipulando el nombre de la prueba.

    Esto probablemente no ayude a la mayoría de las personas, pero alguien sin experiencia en pruebas unitarias escribió un método de prueba que devolvió bool lugar de void :

     [TestMethod] public bool TestSomething() 

    Cambiar el tipo de devolución a void solucionó el problema.

    Asegúrese de tener el paquete xunit.runner.visualstudio en su proyecto de prueba packages.config y también que se haya restaurado correctamente.

    Sé que este no fue el caso de la pregunta original, sin embargo, podría ahorrarle tiempo a alguien como yo.

    Me gustaría agregar que encontré una solución completamente diferente a las anteriores.

    Yo había declarado mi clase de prueba de la siguiente manera:

     [TestClass] class ClassificationTests { //unit tests } 

    ¡Tan pronto como agregué el modificador public a la clase, funcionó como esperaba!

    Si tiene como objective .NET Standard o .NET Core, debe usar el paquete NuGet para NUnit Test Adapter y no la extensión .

    Se recomienda instalar el adaptador de NuGet si está probando proyectos .NET Core o .NET Standard. El adaptador VSIX no es compatible con .NET Core, y no lo es, porque los paquetes VSIX no pueden dirigirse a múltiples plataformas.

    Fuente: NUnit GitHub Wiki

    .

    También consulte las preguntas frecuentes allí:

    Mis pruebas no se muestran en Visual Studio 2017?

    • ¿Estás usando el paquete NuGet?
    • ¿Estás usando la versión 3.8.0 o posterior del paquete NuGet?
    • ¿Sus pruebas se dirigen a .NET Core o al .NET Framework completo? (véase más arriba)
    • ¿Ha agregado una Referencia de paquete a Microsoft.NET.Test.Sdk?
    • ¿Has reiniciado Visual Studio? Todavía es un poco temperamental.

    Fuente: NUnit GitHub Wiki

    Eliminar el archivo \ AppData \ Local \ Microsoft \ VisualStudio \ 14.0 \ 1033 \ SpecificFold erCache.xml resolvió el problema por mí.

    También me mordió esta pequeña característica maravillosa y nada de lo descrito aquí funcionó para mí. No fue hasta que verifiqué la producción de la construcción y noté que los proyectos pertinentes no se estaban construyendo. Una visita al gerente de configuración confirmó mis sospechas.

    Visual Studio 2015 me permitió felizmente agregar nuevos proyectos pero decidió que no valía la pena construirlos. Una vez que agregué los proyectos a la construcción, comenzó a jugar muy bien.

    Cometí el error de crear métodos asíncronos pero volviendo vacío.

    Cambiado: public async void Test()

    A: public async Task Test()

    Lo resolví cambiando X64 a: haga clic con el botón derecho en el proyecto -> Propiedades -> Construir -> Plataforma objective -> Cualquier CPU

    De alguna manera, mi proyecto se configuró para comstackrse como una Biblioteca estática (.lib) . Después de cambiar esto a una biblioteca dinámica (.dll) , Visual Studio 2012 lo prueba correctamente.

     My Unit Test Project -> Properties -> Configuration Properties -> General -> Configuration Type 

    Esto me pasó porque mi proyecto de prueba contenía una app.config . Fue agregado automáticamente por paquetes NuGet para la redirección de ensamblados, pero mis pruebas parecían funcionar bien sin él.

    Ver: https://developercommunity.visualstudio.com/comments/42858/view.html .

    Fue tan fácil para mí solucionar el problema como:

    • Seleccione su Proyecto de Prueba de Unidad
    • Haga clic en el botón ‘Mostrar todos los archivos’ en el Explorador de soluciones y aparecerán nuevos archivos temporales en el árbol de archivos del Explorador de soluciones dentro de ‘obj \ x86 \ Depurar’.
    • Elimine estos archivos temporales y reconstruya el proyecto.
    • ¡Reintentado para ejecutar pruebas y trabajado !.

    Yo tuve el mismo problema. Acabo de limpiar y reconstruir el proyecto y pude ver las pruebas que faltaban.

    Estaba luchando con el mismo problema para VSTest framework y mis pruebas de unidades nativas.

    Entonces, después de hacer todas las cosas que mencionaste antes, eliminé cada aparición del símbolo ‘#’ en la ruta del directorio de mi solución. En realidad funciona

    Lo dejo aquí para los googlers que encontrarán esta pregunta en el futuro.

    Aprovechando para compartir mi solución. Estaba en Windows 10, Visual Studio 2015, NUnit 3.5, NUnit Test Adapter 3.6 (a través de NuGet, no en la extensión VISX) y no se descubrieron ninguna de mis pruebas. Mi problema era que en el proyecto Pruebas de mi solución, de alguna manera se había creado un acceso directo a mi carpeta “Documentos” dentro de la carpeta del proyecto. Supongo que el adaptador de prueba estaba viendo el atajo y se colgó tratando de averiguar qué hacer con él, lo que provocó que no se muestren las pruebas unitarias.

    Este tema está un poco desactualizado, pero mi solución al estado de prueba faltante en VS2015 es:

    El estado de la tarea solo aparece en la configuración de comstackción Debug. Por supuesto, esto también hace que sea imposible depurar su prueba a través del explorador de prueba.