Visual Studio 2015 o 2017 no descubre pruebas unitarias

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

Nota: Este camino está generalmente en C:\Users\(yourusername)\AppData\Local\Temp

Como @Warren-P incluido, puede navegar a la carpeta temp poniendo %temp% en el Menú Inicio, o inicie "Explorador de archivos" e ingrese %temp% en la barra de direcciones.

Podría ser 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

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

• Asegúrese de que la arquitectura del procesador correcta está elegida:
  (Test>Test Settings>Default Processor Architecture)

Una de las razones de 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, 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-beta4 que parece ser parte de la versión oficial de beta4 aspnet5 no funciona en Visual Studio.
2. En su lugar, los paquetes "xunit": "2.1.0-*" y "xunit-runner.dnx": "2.1.0-*" FUNCIONAN en Visual Studio.
3. Para que VS descubra las pruebas, su proyecto DEBE tener un SOLO comando llamado "test" que ejecute "xunit.corredor.dnx". Agregar comandos adicionales puede romperlo.
4. Si la ventana del Explorador de pruebas aún termina vacía, ELIMINA el comando " probar "de tu proyecto, luego vuelve a construir la solución y luego agrega el comando" probar " al proyecto.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 de beta4, no los diarios.

Tuve una instancia en la que algunas pruebas no se recogían porque las había hechoasync como el siguiente:

public async void This_IsMy_UnitTest()

El problema fue que se me olvidó hacerles devolver un Task y no 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 limpia y construye + reiniciar VS.NET que vi correr la prueba y fallar indicando que olvidé agregar el tipo de retorno 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 de borde, pero tener async pruebas para usar await dentro pero no tener la firma correcta puede causar este mismo problema y no es la primera vez que he hecho esto.

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

Tenía el mismo pronlem 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.

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

En mi caso (Visual Studio Enterprise 2015 14.0.25425.01 Update 3, Resharper 2016.2) solo necesitaba hacer una solución limpia desde el menú de compilación. Reconstruyendo la solución, haga que el explorador de pruebas "se despierte" y encuentre todas las pruebas de nuevo.

Simplemente reinicie Visual Studio y en el Explorador de pruebas haga "Ejecutar todo" ... Todas mis pruebas son descubiertas entonces.

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 unitaria en la compilación. Se ha solucionado el problema al volver a una configuración (por ejemplo, Depuración) que incluye todos los proyectos.

En mi caso, MSTest bajo VS 2015 ignoraba 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 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 devolvió bool en lugar de void:

[TestMethod]
public bool TestSomething()

Cambiando el tipo de retorno a void solucionado el problema.

Asegúrese de tener xunit.runner.visualstudio paquete en sus paquetes de proyecto de prueba.config y también que fue correctamente restaurado.

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

Me gustaría añadir 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!

Si está apuntando a.NET Standard o. NET Core, debe usar el paquete NuGet para el adaptador de prueba NUnit y no la extensión.

Se recomienda instalar el adaptador desde NuGet si está probando proyectos.NET Core o. NET Standard. El adaptador VSIX no admite, ni admitirá,. NET Core porque los paquetes VSIX no pueden dirigirse a varias plataformas.

Fuente: NUnit GitHub Wiki

.

También consulte las preguntas frecuentes hay:

¿Mis pruebas no aparecen en Visual Studio 2017?

• ¿Está utilizando el paquete NuGet?
• ¿Está utilizando la versión 3.8.0 o posterior del paquete NuGet?
• ¿Sus pruebas se dirigen a. NET Core o a. NET Framework completo? (véase supra)
• Ha añadido un Paquete de Referencia a Microsoft.NET.Prueba.Sdk?
• ¿Ha reiniciado Visual Studio? Todavía es un poco temperamental.

Fuente: NUnit GitHub Wiki

Apareciendo para compartir mi solución. Yo estaba en Windows 10, Visual Studio 2015, NUnit 3.5, Adaptador de prueba NUnit 3.6 (a través de NuGet, no la extensión VISX) y ninguna de mis pruebas fueron descubiertas. Mi problema era que en el proyecto Tests 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 resultó en el fallo de la unidad de visualización prueba.

Eliminar el archivo \AppData\Local\Microsoft\VisualStudio\14.0\1033\SpecificFolderCache.xml resolvió el problema para mí.

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

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

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

De alguna manera mi proyecto fue configurado para compilar 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

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

Véase: https://developercommunity.visualstudio.com/comments/42858/view.html .

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

• Seleccione su Proyecto de Prueba Unitaria
• 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.
• Volvió a intentar ejecutar pruebas y trabajó!.

Yo tenía 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 unitarias nativas.

Entonces, después de hacer todas esas cosas que mencionaste antes, eliminé cada ocurrencia del símbolo '#' en la ruta del directorio de mi solución. Realmente funciona.

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

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

El task-status solo aparece en la configuración de depuración. Por supuesto, esto también hace que sea imposible depurar su prueba a través del explorador de pruebas.

Asegúrese de que su clase con el [TestClass] atributo public y no private.