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 se desprende que hay 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 he incluido un script en mi propia respuesta que todavía uso hasta el día de hoy para resolver problemas similares cuando aparecen.

Muchas otras respuestas también han resultado útiles para comprender mejor las complejidades del corredor de prueba VS. ¡Aprecio que la gente todavía comparte sus soluciones!

Pregunta original 2015-04-10:

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

Cuando voy al Visual Studio Test Explorer y hago clic en "Ejecutar todo", o cuando hago clic derecho en cualquier método de prueba y selecciono "Ejecutar pruebas", aparece lo siguiente en mi 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 funcionando con Visual Studio 2015 CTP 6 en Windows 10 Pro técnica previa, la acumulación 10041. La versión de .NET Framework no parece importar - sucede en 4.0, 4.5.2y 4.6.

Intenté con los siguientes marcos de prueba y todos dan 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 descubrir las pruebas # 295 , con este comentario del equipo de xunit:

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

Además, asegúrese de haber limpiado la memoria caché del corredor de Visual Studio. Si se corrompe, Visual Studio se comportará permanentemente hasta que se elimine. Para borrar el caché, cierre todas las instancias de Visual Studio, luego elimine la carpeta% TEMP% \ VisualStudioTestExplorerExtensions (sinceramente, probablemente no estaría de más eliminar todo en% TEMP% que pueda eliminarse).

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

Noté que ReSharper en realidad es capaz de 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 muchas de ellas y no todas pueden eliminarse sin efectos secundarios no deseados.

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

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

Como @ Warren-P incluido, puede navegar a la carpeta temporal %temp%ingresando %temp%en el menú Inicio o iniciar "Explorador de archivos" e ingresar en la barra de direcciones.

Es posible que su código esté compilado con x64, por lo tanto, debe habilitar la Arquitectura de procesador predeterminada como X64.

Test > Test Settings > Default Processor Architecture > X64

• Compruebe si NUnit Test Adapter 2/3 está instalado en VisualStudio.
  (Tools>Extensions and Updates )

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

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

Este problema aún regresa de vez en cuando. Escribí un pequeño fragmento de PowerShell para automatizar la eliminación de la caché / carpeta / archivos relevantes 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. Solo omite el "$env:TEMP".

Respuesta original 12/04/2015

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

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

Estos son los pasos exactos que he tomado:

1. Visual Studio cerrado
2. Se utilizó CCleaner para borrar temparchivos / carpetas del sistema y del navegador

3. Eliminó / eliminó 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 pruebas, entonces debe instalar el Adaptador de prueba NUnit. Descargue el adaptador desde 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-beta4que parece ser parte de la versión oficial beta4 aspnet5 no funciona en Visual Studio.
2. En cambio, el uso "xunit": "2.1.0-*"y los "xunit-runner.dnx": "2.1.0-*"paquetes funcionan en Visual Studio.
3. Para que VS descubra las pruebas, su proyecto DEBE tener un solo comando llamado "prueba" que ejecute "xunit.runner.dnx". Agregar comandos adicionales puede romperlo.
4. Si la ventana de su Explorador de pruebas todavía termina vacía, RETIRE el comando "prueba" de su proyecto, luego reconstruya la solución, luego agregue el comando "prueba" nuevamente a project.json.
5. Borrar todas sus cachés según la sugerencia de @ Fred-Kleuver puede ayudar, pero no he hecho todos los pasos de 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 no se tomarían algunas pruebas porque las había hecho de asyncla siguiente manera:

public async void This_IsMy_UnitTest()

El problema fue que olvidé hacer que regresaran Tasky no voidcuando hice el cambio. Uno pensaría 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 limpiezas y compilaciones + reinicio VS.NETque vi que la prueba se ejecutaba y fallaba, lo que indica que olvidé agregar el Tasktipo de retorno:

public async Task This_IsMy_UnitTest()

Después de la actualización, las pruebas unitarias se encontraron y funcionaron correctamente. Este podría ser un caso extremo, pero tener asyncpruebas para usar awaitdentro pero no tener la firma correcta puede causar este mismo problema y no es la primera vez que lo hago.

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

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

Simplemente reinicie Visual Studio y en Test Explorer haga "Ejecutar todo" ... Todas mis pruebas se descubren entonces.

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. La reconstrucción de la solución hace que el explorador de prueba "se despierte" y encuentre todas las pruebas nuevamente.

La solución en mi caso fue simplemente instalar la extensión del adaptador de prueba NUnit 3 en mi Visual Studio 2015.

En mi caso, el problema era "entre la silla y el teclado". Había cambiado a una configuración en el Administrador de configuración que no incluía mis proyectos de prueba de unidad en la compilación. Volver a una configuración (por ejemplo, Depuración) que incluye todos los proyectos solucionó el problema.

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

Esto probablemente no ayudará a la mayoría de las personas, pero alguien sin experiencia en pruebas unitarias había escrito un método de prueba que devolvía en boollugar de void:

[TestMethod]
public bool TestSomething()

Cambiar el tipo de retorno para voidsolucionar el problema.

Asegúrese de tener el xunit.runner.visualstudiopaquete 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.

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

Había declarado mi clase de prueba de la siguiente manera:

[TestClass]
class ClassificationTests
{
   //unit tests
}

¡Tan pronto como agregué el publicmodificador a la clase, funcionó como se esperaba!

Si está apuntando a .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 ni será compatible con .NET Core porque los paquetes VSIX no pueden apuntar a múltiples plataformas.

Fuente: Wiki de NUnit GitHub

.

Consulte también las preguntas frecuentes allí:

¿Mis pruebas no se muestran en Visual Studio 2017?

• ¿Estás usando el paquete NuGet?
• ¿Está utilizando 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: Wiki de NUnit GitHub

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

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

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

Apareciendo 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 la extensión VISX) y no se descubrió ninguna de mis pruebas. Mi problema fue que en el proyecto de Pruebas de mi solución, de alguna manera se creó un acceso directo a mi carpeta "Documentos" dentro de la carpeta del proyecto. Supongo que el adaptador de prueba estaba viendo el acceso directo y se estaba quedando colgado tratando de averiguar qué hacer con él, lo que resultó en la falla al mostrar las pruebas unitarias.

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

Este tema está algo desactualizado, pero mi solución al estado de prueba que falta en VS2015:

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

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

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

Lo resolví cambiando X64 a: Haga clic derecho en proyecto -> Propiedades -> Compilar -> Objetivo de plataforma -> Cualquier CPU

De alguna manera, mi proyecto se configuró para compilarse como una biblioteca estática (.lib) . Después de cambiar esto a una Biblioteca dinámica (.dll) , las pruebas fueron descubiertas correctamente por Visual Studio 2012.

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

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 \ Debug'.
• Elimine estos archivos temporales y reconstruya el proyecto.
• ¡Reintentado para ejecutar pruebas y trabajado !.

Tuvimos el mismo problema. Tenemos una gran solución VS 2015 con múltiples proyectos de C # e incluso más proyectos de prueba.

El descubrimiento de prueba de Resharper funcionó bien, pero VS Test Explorer falló miserablemente.

Resulta que los proyectos no tenían la misma versión de MsTest TestFramework y TestAdapter, y que a veces usaban NuGets y otras veces buenas referencias antiguas, y eso aparentemente no es compatible (tanto para un IDE tan costoso).

Eliminar todas las referencias de Microsoft.VisualStudio.Test * y luego agregar / actualizar los dos NuGets de MSTest solucionó el problema.

Resolví este problema al darme cuenta de que el Marco de destino para mi proyecto de prueba era diferente del proyecto bajo prueba. Sí, causé este problema al cambiar el marco de destino del predeterminado (Proyecto> Propiedades> Aplicación), pero no lo hice para el proyecto de prueba, que se creó varias semanas después. La falta de coincidencia no causó un error del compilador, pero sí generó una advertencia en la ventana Lista de errores . Una vez que seleccioné la opción para mostrar advertencias, la solución fue obvia.