Visual Studio 2015 o 2017 no descubre pruebas unitarias


165

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.


3
Estoy tan contento de haberme topado con esto, me recuerda por qué estoy usando un corredor de prueba de terceros (en mi caso, ncrunch). Renuncié a mstest hace mucho tiempo por razones similares. Por supuesto, esa no es la solución si estás atrapado con mstest ...
Abel


con VS 2017, increíblemente, una limpieza de mis carpetas relacionadas con temp y localappdata VS2017, una solución de cierre + recarga + limpieza y un reinicio de Windows no ayudaron. Sin embargo, sorprendentemente, un proyecto simple de "descarga - recarga" en solo uno de mis proyectos de prueba ayudó a que el descubrimiento de la prueba dejara de colgarse. No uso el paquete de prueba de unidad de terceros.
Pac0

Para algunas personas esto podría ser interesante o más relevante (no creo que deba agregarlo como respuesta): No hay fuente disponible en Test Explorer - github.com/Microsoft/testfx/issues/274
hB0

Esto podría ser una solución para alguien stackoverflow.com/a/58019304/1566372
Rady

Respuestas:


154

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.


30
O simplemente escriba en %TEMP%el menú Iniciar ejecución y encontrará su carpeta temporal sin que adivine cuál es el valor de temp.
Warren P

65
@ ZéCarlos Cualquier aplicación que almacene datos importantes en el %TEMP%directorio merece dejar de funcionar.
Mark Pattison

25
no es una vergüenza para usted, es un completo fracaso de Microsoft que tenga que tomar medidas tan ridículas para mantener en funcionamiento un IDE de más de 1000 USD.
MushyPeas

8
¡También funcionó para mí en VS2017!
Lorentz Vedeler

66
Si le preocupa borrar todo el directorio temporal, solo borrar el subdirectorio Temp \ VisualStudioTestExplorerExtensions parece solucionar el problema.
Mike Walsh

90

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

3
Esto me ha mordido algunas veces. Incluso después de todos estos años, todavía no puedo pensar en una buena razón por la cual, por defecto, la configuración de prueba no se selecciona para que coincida automáticamente con la configuración de compilación actual del proyecto. Simplemente me parece una configuración duplicada sin sentido.
Neutrino

1
La actualización de Windows y / o la actualización VS cambia la arquitectura predeterminada sin avisarle ... aaargh
rupweb

Y 4 años después, esto sigue siendo útil. Gracias
Oscar O.

67
  • 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)


2
Esto es lo que finalmente funcionó para mí. Después de probar todo lo demás.
BradStell

Te hace sentir como un tonto hurgando en las carpetas temporales primero cuando la extensión ni siquiera está instalada. Gracias por publicar esto.
NightOwl888

2
También verifique si usa la extensión correcta. Hay uno separado para NUnit 2.xy NUnit 3.x.
pmbanka

1
Cuando se dirige a .NET Standard, en realidad necesita instalar el adaptador de prueba NUnit del paquete NuGet en lugar de una extensión VSIX. github.com/nunit/docs/wiki/.NET-Core-and-.NET-Standard
m93a

Intente obtener NUnit3TestAdapter de nuget, en lugar de VSIX. Ese es el mejor enfoque
ravella

33

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

Gracias, funcionó para mí después de borrar las carpetas Microsoft \ VisualStudio \ 14.0 \ y Microsoft \ VisualStudio Services \ 6.0 \ Cache que usted describe.
Niels van Reijmersdal

¿Seguramente quieres decir \Microsoft\VisualStudio\14.0\ImageLibrary\ImageLibrary.cache?
Mateen Ulhaq

2
He eliminado todo de% TEMP% y no funciona, pero cuando leí el directorio 'VisualStudioTestExplorerExtensions' (vacío) todo funciona perfectamente :-) (Hay una respuesta con esa solución en la parte inferior en el día actual)
nilphilus

Quiero confirmar que esta solución funciona para mí con VS2015 Update 3 y Resharper 10. Pero necesita reiniciar para ver el milagro
Quoc Nguyen

1
Eliminé solo un archivo \ AppData \ Local \ Microsoft \ VisualStudio \ 14.0 \ 1033 \ SpecificFolderCache.xml que contiene
Serhii Kuzmychov

21

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


1
Si bien esto no es 100% correcto y tuve una clase no pública funcionando bien, en algún momento su prueba unitaria dejó de funcionar. Cuando cambié la clase de prueba unitaria a pública, comenzó a funcionar nuevamente. ¡Imagínate!
SashaArz

Esto lo resolvió para mí. De forma predeterminada, Visual Studio agrega clases de prueba sin la palabra clave pública, y no las vería hasta que las hiciera públicas.
Marc Fearby

13

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.


2
Siguiendo sus instrucciones, busqué "nunit" y encontré "NUnit 3 Test Adapter" que, después de "Descargar" (instalar), resolvió mi problema. Al buscar en Internet este problema, se encuentra otro artículo de SO en el enlace
Adam Cox

Esto es mejor que el administrador de paquetes Nuget en algunos escenarios, ya que no cambia los archivos de configuración
GY_

1
@GY_ pero cuando se dirige a .NET Core o Standard, realmente necesita el paquete NuGet, consulte mi respuesta a continuación: stackoverflow.com/a/47460221/1137334
m93a

Salvas mi vida ! Gracias, probé muchas soluciones y no funcionó. El mío fue el adaptador de prueba de google.
Erman

9

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.


1
De acuerdo, he confirmado (al pedirle a un compañero de trabajo que lo intente) que la solución anterior no requiere que se borren las cachés o los archivos temporales.
Avi Cherry

Arriba dice "En su lugar, usando" xunit ":" 2.1.0- "y" xunit-runner.dnx ":" 2.1.0- "los paquetes funcionan en Visual Studio". Esto funciona, gracias!
Gillardo

Por cierto, como seguimiento, todo parece funcionar bien ahora en VS 2015 a partir de los lanzamientos actuales. No es necesario preocuparse para que aparezcan nuevas pruebas ni nada.
Avi Cherry

1
Finalmente, ahora hay una guía adecuada de MS sobre exactamente qué versiones de xunit usar con qué versiones de DNX, aquí: xunit.github.io/docs/getting-started-dnx.html
Avi Cherry

9

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.


¡Resolvió el problema por mí!
Aimal Khan

8

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

ingrese la descripción de la imagen aquí


Gracias, en mi caso tuve NUnitTestAdapter en lugar de NUnit3TestAdapter. Eso resolvió mi problema.
píxel

Agregar el paquete nuget NUnit3TestAdapter a una solución o a un proyecto no solucionaría el problema para todas las demás soluciones en general, sino solo para aquellas a las que se ha agregado. Para hacerlo generalmente para todas las soluciones / proyectos, agregue la extensión del adaptador de prueba NUnit 3 a su estudio visual como se explica en stackoverflow.com/a/45748818/1300390
Umar T.

6

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.


6

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


1
También he notado que simplemente cierro Test Explorer y lo vuelvo a abrir y elegir Ejecutar todo también funciona. Todavía no estoy seguro si siempre funciona, pero esta vez funcionó.
Rico

5

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.


5

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

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


¿Cómo su respuesta agrega valor a la pregunta? ¿Los has leído? Ya hay dos respuestas que recomiendan exactamente la misma solución: stackoverflow.com/a/41364951/6305294 , stackoverflow.com/a/35043380/6305294
Alex

2
Bueno, leí el primero (es decir, stackoverflow.com/a/41364951/6305294) pero eso es diferente a mi respuesta, ya que sugiere agregar el paquete Nuget del adaptador NUnit a una solución o un proyecto, que no solucionaría el problema. problema para todas las demás soluciones en general. Con respecto al segundo, debo admitir que me perdí de verlo. Quizás agregar una captura de pantalla ayude a captar la atención cuando hay dos respuestas a una pregunta
Umar T.

4

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.


4

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.


4

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.


Todavía interesante saber que devolver un tipo impide el descubrimiento de la prueba, no lo sabía.
Fred Kleuver

3

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.


3

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!


2

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



1

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


1

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.


1

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


1

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.


1

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.


1

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


1

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

1

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

1

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.


1

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.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.