unit testing - net - Visual Studio 2015 o 2017 no descubre pruebas unitarias

pruebas unitarias visual basic net

Question

EDITAR 2016-10-19:

La pregunta original era sobre un problema específico de VS2015 CTP6 con el corredor de prueba XUnit. A partir 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 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 ejecutando Visual Studio 2015 CTP 6 en Windows 10 Pro Technical Preview, compilació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 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 realmente 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 muchas de ellas y no todas pueden eliminarse sin efectos secundarios no deseados.

Answer 1

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 el borrado de los archivos / carpetas temporales / caché relevantes. 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 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 archivos / carpetas temp 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

Answer 2

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 estaba colgado tratando de averiguar qué hacer con él, lo que resultó en la falla al mostrar las pruebas unitarias.

Answer 3

Asegúrese de tener el paquete xunit.runner.visualstudio en su proyecto de prueba packages.config y que también 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.

Answer 4

De alguna manera, mi proyecto estaba configurado 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

Answer 5

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

Answer 6

En Visual Studio 2015 (Actualización 3), si desea adjuntar las pruebas en el explorador de prueba, 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.

Answer 7

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.

Answer 8

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ó mediante adivinar y verificar manipulando el nombre de la prueba.

Answer 9

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.

Answer 10

Es posible que sus códigos estén compilados con x64, por lo tanto, debe habilitar la arquitectura de procesador predeterminada como X64.

Test > Test Settings > Default Processor Architecture > X64

Answer 11

Estaba luchando con el mismo problema para el marco VSTest y mis pruebas unitarias nativas.

Entonces, después de hacer todas esas cosas que mencionó 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.

Answer 12

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.

Answer 13

Esto me sucedió porque mi proyecto de prueba contenía una 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 .

Answer 14

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 bool lugar de void :

[TestMethod]
public bool TestSomething()

Cambiar el tipo de retorno a void solucionó el problema.

Answer 15

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 !.

Answer 16

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

Answer 17

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

Answer 18

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, el uso de los "xunit": "2.1.0-*" y "xunit-runner.dnx": "2.1.0-*" 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.

Answer 19

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

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

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

Answer 20

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 admite, y no admitirá .NET Core porque los paquetes VSIX no pueden apuntar a múltiples plataformas.

Fuente: github.com/nunit/docs/wiki/.NET-Core-and-.NET-Standard

.

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: github.com/nunit/docs/wiki/.NET-Core-and-.NET-Standard

Answer 21

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

Answer 22

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 modificador public a la clase, funcionó como se esperaba!

Answer 23

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 me di cuenta de 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.

Answer 24

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.

Answer 25

Tuve una instancia en la que algunas pruebas no se tomarían porque las hice async la siguiente manera:

public async void This_IsMy_UnitTest()

El problema fue que olvidé hacer que devolvieran una Task y no se void cuando 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 + reiniciando VS.NET cuando vi que la prueba se ejecutaba y fallaba, lo que indica que olvidé agregar el tipo de retorno de Task :

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 pruebas async para usar dentro de await pero no tener la firma correcta puede causar este mismo problema y no es la primera vez que lo hago.

Answer 26

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.

Answer 27

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

Answer 28

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

Answer 29

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

Answer 30

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

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