Visual Studio 2013 no descubre pruebas unitarias


146

Tengo una solución simple en Visual Studio 2013 que está compuesta por un proyecto web, un proyecto de biblioteca y un proyecto de prueba de unidad. Cuando abro la solución e intento ejecutar las pruebas unitarias, Visual Studio no las descubre. Para ejecutar las pruebas, intento ir al menú y elegir Prueba -> Ejecutar -> Ejecutar todas las pruebas o abriendo la ventana del explorador de pruebas. Según los métodos, Visual Studio no descubre ninguna prueba en la solución.

Creando primero un proyecto simple de pruebas unitarias e intentando ejecutar la prueba, Visual Studio sabe descubrir la prueba y puedo ejecutarla. Luego, si abro mi solución anterior, Visual Studio ahora descubre todas las pruebas. Intento guardar mi solución, pero al cerrarla y volver a abrirla, sin crear primero un proyecto de prueba unitaria, el estudio visual no vuelve a encontrar las pruebas. Este es un comportamiento muy extraño que no sé por qué sucede esto.

Solía ​​trabajar solo en este proyecto que usaba el control de fuente git integrado con la base del equipo del estudio visual. El problema de Visual Studio no descubre que las pruebas unitarias comienzan cuando un nuevo elemento llegó al proyecto y cuando necesito recrear la solución a través del control de fuente en línea. Antes de esto, todas las pruebas siempre fueron descubiertas por Visual Studio.

Para la creación de las pruebas unitarias, uso el dll Microsoft.VisualStudio.QualityTools.UnitTestFramework. Mi versión de Visual Studio es: Microsoft Visual Studio Express 2013 para Web Versión 12.0.30723.00 Actualización 3. Mi versión de .net framework es 4.5.50938.

Todas mis pruebas son así:

[TestClass] 
public class Service1Test 
{ 
    [TestMethod] 
    public void Test1() 
    {
        Assert.IsTrue(True); 
    } 
}

2
¿Son estas pruebas unitarias basadas en Async?
Jamie Keeling

No estoy seguro de cuál era el problema, pero ejecutarlo como administrador me solucionó el problema.
Sriram Sakthivel

Todas las pruebas unitarias basadas en sincronización
miguelbgouveia

2
¿Has probado un corredor de prueba externo (como ReSharpers o NCrunch)? Tal vez su instalación tiene errores (así que reinstale VS)
Carsten

1
Ninguno de estos solucionó el problema para mí :( Qué desastre. He renunciado a NUnit y estoy confiando en UnitTestFramework - extrañamente el problema opuesto al OP
Adam

Respuestas:


210

Algunas cosas que he notado que tengo que hacer de vez en cuando para que las pruebas se muestren correctamente.

  1. Si su solución está en una unidad protegida a la que necesita acceso de administrador para leer / escribir, a veces solo aparece una parte de las pruebas. Definitivamente ejecute VS como administrador en ese caso.

  2. Si su solución es de 64 bits, asegúrese de que Prueba> Configuración de prueba> Arquitectura de procesador predeterminada esté establecida en x64. A veces se establece en x86. Configúrelo en x64, luego reconstruya.

  3. A veces, simplemente reiniciar Visual Studio hace el truco porque el explorador de prueba se iniciará nuevamente.

  4. No olvides construir el proyecto / solución de prueba. (Si desea que se cree con el resto de los proyectos, haga clic con el botón derecho en su solución> Propiedades> Propiedades de configuración> Configuración> marque la casilla "Compilar" para su proyecto de prueba)

  5. Asegúrese de que las pruebas estén en una publicsección de su clase de prueba


34
Me doy cuenta de que esta respuesta llega un poco tarde, pero mi búsqueda en Google me trajo aquí, y nada de lo mencionado resolvió mi problema. Finalmente, descubrí que era el número 2 en mi lista, por lo que quería dejar ese conocimiento, además de los otros trucos que aprendí con el tiempo.
AndyG

77
Una combinación de # 2 y # 3 lo hizo por mí. Visual Studio se quejó de que varios proyectos (no de prueba) en mi solución se excluyeron del paso de descubrimiento de prueba porque se crearon para x86, pero eso estuvo bien.
Nate Barbettini

44
Descubrí que mi configuración era correcta y que reiniciar no funcionaba. Lo que solucionó el problema para mí fue simplemente construir la solución. Sé que esto puede parecer tonto, pero no es obvio que sea necesario; No he visto ninguno de los documentos oficiales mencionar este paso.
user1807768

66
Tuve el mismo problema en VS2015. # 2 solucionó el problema para mí.
mcolegro

2
No tengo idea de por qué la gente paga tanto dinero por un producto que falla con tanta frecuencia. Tuve que actualizar mi proyecto a 2015 y hacer el # 3 2 veces antes de que descubriera mi prueba.
Matthew Hoggan el

81

Si usa NUnit, asegúrese de descargar primero el Adaptador NUnit.

Vaya a Herramientas → Extensiones y actualizaciones ... → En línea → busque "Adaptador de prueba NUnit".


2
Estoy usando UnitTests de Microsoft. En este caso supongo que no es necesario instalar nada.
miguelbgouveia

1
Esto lo hizo por mí, muy obligado.
Matas Vaitkevicius

Eso me lo arregló. Gracias.
jjthebig1

Votado como resolvió el problema, pero es necesario tener un adaptador NUnit o Visual Stdio debería funcionar con NUnit listo para usar.
Owain Glyndŵr

Eres un dios señor.
Nox

61

Asegúrese de que su clase de prueba sea publicpara que pueda encontrarla. Y si hace referencia a otra clase, asegúrese de lo mismo.

Además, a veces si no tiene Afirmaciones o no está decorando la prueba con a [TestMethod], es posible que no se reconozca una prueba.

2 cosas más: 1) Las pruebas unitarias asíncronas son divertidas en el mejor de los casos, y ninguna en el peor. Eche un vistazo a este artículo de Stephen Cleary y manténgase allí si le interesa.

2) Si usa NUnit y se encuentra con los mismos problemas, tenga en cuenta que es [TestCase]para Nunit, en lugar de[TestMethod]

Habiendo dicho lo anterior, aquí hay un artículo que publiqué sobre el proyecto de código, con ambos MSTesty NUnit, en caso de que quieras darle una vuelta y asegurarte de que no te pierdas nada.


1
Todas mis pruebas son así: [TestClass] public class ServicesUtilsTest {[TestMethod] public void Test1 () {Assert.IsTrue (True); }}
miguelbgouveia

Esto no está muy claro. Póngalo en un bloque de código en su pregunta, para que se pueda entender :)
Noctis

Todas mis pruebas son para el código de sincronización, y creo que mi problema no está en el código de las pruebas unitarias, sino más en Visual Studio, a veces no descubriendo las pruebas.
miguelbgouveia

Intente usar esto en su lugar:using Microsoft.VisualStudio.TestTools.UnitTesting;
Noctis

1
Ya estoy usando Microsoft.VisualStudio.TestTools.UnitTesting. Este espacio de nombres se define en el
archivo

28

Tuve el mismo problema pero ninguna de las otras soluciones funcionó. Resulta que estaba usando el marco NUnit 3 con el adaptador 2.

Si está utilizando NUnit 3, vaya a Extensiones y actualizaciones e instale el Adaptador de prueba NUnit3.


Lo dice en la descripción del paquete Nuget. Pero si eres como yo y no lees, espero que esto ayude: "Este paquete incluye el ensamblado de marco NUnit 3.0, al que hacen referencia tus pruebas. Necesitarás instalar la versión 3.0 del nunit- programa de consola o un corredor de terceros que admita NUnit 3.0 para ejecutar pruebas. Los corredores destinados a usarse con NUnit 2.x no ejecutarán las pruebas 3.0 correctamente ".
Frank

En mi caso, sabía que tenía algo que ver con la actualización de NUnit3, pero una serie de mi prueba pasó y las otras no se vieron. Tras una inspección más cercana, hubo muchas excepciones en la salida, a pesar de que todas las pruebas pasaron.
Rich Shealer

Este fue el caso para mí también. Ejecuté nuget "update-package" sin darme cuenta de que se actualizó de NUnit 2.xa 3.x.
Jens

Actualmente, el adaptador de prueba NUnit 3.0 no se puede encontrar a través de NuGet (consulte el Wiki de NUnit 3.0 ). Sin embargo, todavía puede instalarse como una extensión.
vauhochzett

1
Muchas gracias Frank. Resolvió mi problema. Ahora puedo ver los resultados de la prueba de la unidad en la ventana de la consola :)
santosh kumar patro

12

Tengo este problema de vez en cuando. Lo que funciona para mí es cerrar Visual Studio e ir a la carpeta:

%LocalAppData%\Microsoft\VisualStudio\12.0\ComponentModelCache

y eliminarlo contenido.

Una vez que abra Visual Studio y cargue su proyecto nuevamente, el Explorador de pruebas debería contener sus pruebas


Para mí eso no funciona. Estoy usando Visual Studio 2013 Express con la instalación de la actualización 5 recientemente. Todavía no aparecen pruebas unitarias.
miguelbgouveia

Esto también fue lo que trabajador para mí. Incluso trabajó sin reiniciar el estudio visual. Horas por el desagüe finalmente tuvieron un final.
Stephan Ryer

Este directorio ya no existe en VS2017.
Noel Widmer

Gracias, funciona para mí para cualquiera de los que esta carpeta puede tener una versión diferente dependiendo de la instalación de Visual Studio como para mí es%LocalAppData%\Microsoft\VisualStudio\16.0_03b7a93c\ComponentModelCache
Ravi Kumar Mistry

12

Los usuarios de XUnit pueden notar que la ventana Explorador de pruebas ya no enumera ninguna prueba. Para que las pruebas sean reconocibles nuevamente, pruebe este consejo importante , resaltado a continuación.

Si tiene problemas para descubrir o ejecutar pruebas, puede ser víctima de un caché de corredor dañado dentro de Visual Studio. Para borrar esta caché, cierre todas las instancias de Visual Studio, luego elimine la carpeta% TEMP% \ VisualStudioTestExplorerExtensions. También asegúrese de que su proyecto solo esté vinculado a una única versión del paquete NuGet de Visual Studio Runner (xunit.runner.visualstudio).

Escriba TEMP para encontrar la carpeta de destino


Esto no funcionó para mí. El explorador de pruebas simplemente no encuentra mi prueba y, por lo que puedo decir, no lo estoy haciendo mal y he probado algunas de las soluciones aquí sin éxito.
Skychan

Usando MsTestV2 - esto fue lo único que solucionó el problema
Nathan

5

Para futuros googlers tuve un escenario raro que causó esto.

En mi clase de prueba base tenía una propiedad llamada TestContext. Esto interfirió con la propiedad TestContext reservada de MSTest causando que todas mis pruebas estuvieran ocultas de VS / Resharper excepto una (que no se heredaba de la base).


1
¡también me tienes! Olvidé hacer la propiedad de contexto de prueba public.
escape-llc

4

para mí estaba cambiando las 'configuraciones de solución' a Debug (en lugar de Release).


4

Mi problema fue porque mi método de prueba de unidad no era nulo y estaba recibiendo parámetros.


De todas las cosas ... Este fue mi problema y el params bit tiene sentido. Después de todo, ¿qué sabría pasar el sistema de prueba? La solución es hacer un método de prueba en el que llame manualmente al método que desea probar. Si está probando un proyecto WebAPI y tiene un parámetro Get with params, aún debe tener la llamada Get correspondiente pero no se mostrará en el explorador.
MetalPhoenix

4

He descubierto que los métodos de prueba de unidad marcados como async voidno son descubiertos por VS Test Explorer. Esto parece deberse a que VS no tendría forma de esperar a que termine una prueba y decidir si tuvo éxito o no. Si realmente necesita tener un método de prueba para ejecutarse de forma asíncrona, haga que devuelva una tarea como async Task. Descubrí que esto solucionó el problema para mí.


1
Esto no responde la pregunta anterior, pero este es exactamente el problema que estaba tratando de resolver. Así que tuviste un accidente +1 :) ¡Muchas gracias!
CF

3

Intente compilar todos los proyectos como MSIL (cualquier CPU) en lugar de x86 / x64. Trabajó para mí extrañamente


Solo tuve que construir el proyecto de prueba usando cualquier CPU, los otros proyectos permanecieron x64
Eduardo Brites

1
Técnicamente, C # / VB.NET siempre compila a MSIL. La configuración del proyecto "x86", "x64" o "Cualquier CPU" (y, en las versiones más nuevas, "Prefiero 32 bits") son solo banderas en la parte superior del EXE / DLL. Sin embargo, Point sigue en pie; NUnit no enumerará las pruebas que no puede cargar en el motor de ejecución, debido a que están marcadas como que requieren una arquitectura particular para ejecutarse.
Jonathan Gilbert

3

Si bien la solución de AndyG funciona, una solución más duradera podría ser establecer la variable de entorno PreferredToolArchitecture en "x64", ya sea mediante:

Cómo hacer que Visual Studio use la cadena de herramientas nativa amd64

o por:

  • Panel de control | Sistema y Seguridad | Sistema | Configuración avanzada del sistema | Variables de entorno
  • PreferredToolArchitecture = x64
  • DefaultToolArchitecture = Native64Bit
  • PROCESSOR_ARCHITECTURE = x64
  • ProcesadorArquitectura = x64

2

Estaba enfrentando el mismo problema y he recordado, nuevamente (esta situación sucedió antes), que seleccionar "Plataforma Mixta" en el menú de la plataforma de soluciones funciona, así como las otras respuestas.


Pero, ¿dónde está el menú de la plataforma de soluciones? ¿Eso es en Visual Studio? Estoy usando Visual Studio Express 2013 para Web y no puedo encontrar ese menú.
miguelbgouveia

2

Había logrado agregar el mío como

public static void TestMethod1(){}

comenzó a funcionar una vez que eliminé la estática ...


2

Vaya al administrador de paquetes Nuget y descargue Nunit Adapter de la siguiente manera. ingrese la descripción de la imagen aquí


1

vaya al menú del proyecto> Configuration Manager, verifique que la plataforma de su proyecto de prueba coincida con el resto del proyecto y verifique la construcción y luego la reconstrucción.


1
No tengo ninguna opción de Configuration Manager en el menú de mi proyecto. Solo puedo encontrar la opción de propiedades del proyecto. Yo mismo la plataforma del proyecto de pruebas unitarias y es el mismo de los otros proyectos. Entonces, para mí, esta solución no funciona.
miguelbgouveia

Definir "coincide con el resto del proyecto"
amalgamate

1

Me encontré con esto y no vi un caso similar que fuera similar al mío.

En el .csprojarchivo de mi proyecto de prueba, la privacidad de referencia de NUnit se estableció en False:

<Reference Include="nunit.framework, Version=2.6.4.14350, Culture=neutral, PublicKeyToken=96d09a1eb7f44a77, processorArchitecture=MSIL">
  <HintPath>..\packages\NUnit.2.6.4\lib\nunit.framework.dll</HintPath>
  <Private>False</Private>
</Reference>

Después de que me puse <Private>a Truetrabajar, funcionó.


1

Solo necesita instalar este paquete solamente:

NUnit TestAdapter NUnit TestAdapter


Sabía que usar otro marco de prueba de unidad resolverá mi problema. Pero si quisiera continuar usando el marco de Microsoft Unit Tests, esa no es una solución.
miguelbgouveia


1

Tuve exactamente el mismo problema.

Fue debido a una versión incompatible de NUnit que había agregado a mi proyecto (3.2.0) y al Adaptador de prueba que había instalado (2.0.0).

Para solucionarlo, use "Herramientas> Extensiones y actualizaciones" y busque el Adaptador de prueba NUnit3, descubrió mis pruebas después de eso.

Salud


No estoy usando NUnit.
miguelbgouveia

1

Digamos, por el bien de los argumentos, que necesita usar la arquitectura X64 en su proyecto de prueba para que las dependencias se construyan correctamente (como en mi caso). Es posible que deba modificar su arquitectura de procesador predeterminada en el menú Prueba - Configuración de prueba . Establecer esto en X64 permitió a mi explorador de pruebas encontrar mis pruebas usando Microsoft.VisualStudio.TestTools.UnitTesting.


1

Perdón por agregar a la larga lista, pero tuve un problema completamente diferente. Primero, me gustaría mencionar que descubrí mi problema al hacer clic en 'Ejecutar todo' en el Explorador de pruebas y luego mirar la ventana de salida de compilación en Visual Studio. Tienes que mirarlo activamente, ya que luego desaparece el mensaje.

En cuanto al problema, parece que durante el escaneo de las pruebas, la DLL se carga y se enumeran sus tipos de prueba. Esto hace que se carguen las referencias y si ocurre alguna falla durante este proceso, las pruebas no se mostrarán en el explorador. Tuve dos problemas que impiden que la DLL de prueba se cargue correctamente:

  • Todavía quedaba una redirección vinculante en el archivo de configuración (redirigiendo a una versión inferior a NHiberate de la que se hizo referencia en el proyecto de prueba).
  • Una referencia de ensamblado en conflicto (las referencias de segundo nivel no se pueden cargar). AsmSpy es, por cierto, una gran herramienta para buscarlos .

Estaba enfrentando el mismo problema, me costó encontrar qué dlls no se cargaban ...
amarnath chatterjee

1

Si carga una solución de Visual Studio (VS 2015 Community en mi caso) desde un recurso compartido de red o el directorio Mis documentos que es parte de un recurso compartido , se encontrará con este problema. Lo resolví moviendo la solución y sus proyectos subyacentes a una carpeta local.


1

Después de pasar 2 días ... nada de lo anterior funcionó para mí. La única "solución" fue: Ir a las propiedades del proyecto -> Crear pestaña. Luego haga clic en el botón Avanzado en la esquina inferior derecha del panel. Cambie "Información de depuración:" a "completo" y haga clic en Aceptar.

Aquí están las capturas de pantalla: ingrese la descripción de la imagen aquí

ingrese la descripción de la imagen aquíingrese la descripción de la imagen aquí


0

Me encontré con el mismo problema. E investigó y descubrió que los dll no se compilaron y se colocaron en la carpeta correcta. tan pronto como cambié mi configuración, aparecieron. - las opciones de compilación de Proyectos, ¿qué carpeta se debe usar? - la configuración de compilación de la entrada del menú de compilación, deben verificarse.

Eso me lo arregló.


Para mí, los dll para las pruebas tampoco se crearon porque Visual Studio no encuentra ninguna prueba definida. Estoy usando Visual Studio Express y no tengo la entrada del menú Generar. Pero en mi administrador de configuración tengo todas las opciones de compilación marcadas. Entonces, creo que ese no es el problema para mi caso.
miguelbgouveia

@miguelbgouveia, es al revés: VS crea archivos DLL y luego los escanea en busca de pruebas. Entonces, si no tiene DLL de proyecto de prueba, definitivamente no encontrará pruebas.

0

Para Visual Studio 2013.5, la limpieza del directorio \ TestResults en la solución ayudó. Visual Studio corrompió el archivo mdf en el que almacena las pruebas descubiertas, evitando así el descubrimiento de pruebas unitarias.


1
Está en la solución de su proyecto. Haga clic con el botón derecho en el archivo del proyecto en el Explorador de soluciones -> Abrir carpeta en el Explorador de archivos. Vaya un directorio hacia arriba desde allí y elimine el directorio / TestResults. Puede que tenga que cerrar Visual Studio para eliminar todo. Reconstruirá el directorio la próxima vez que se abra el proyecto.
MartijnK

0

Asegúrese de que todos sus proyectos se ejecuten con la misma configuración. En Propiedades de su proyecto => Depurar => Plataforma en la lista desplegable, elija la plataforma adecuada (para mí fue "Cualquier CPU") según lo determinado en sus otros proyectos.


0
  • Sé que las pruebas unitarias no se encuentran si la solución no está construida, por lo que es algo para probar (construir la solución), pero esa solución es como la mesa de ayuda preguntando si su computadora está conectada ...
  • Después de que una reconstrucción limpia no solucionó el problema para mí, ejecutar una compilación por lotes completa lo solucionó.

0

Tuve el mismo problema; Las pruebas de repente dejaron de ser descubiertas.

El adaptador de prueba Nunit se había deshabilitado de alguna manera. Al hacer clic en habilitar en el administrador de extensiones lo arregló para mí.


0

Tuve el mismo problema hasta que me di cuenta de que cometí un error de cortar / pegar y lo dejé [Test Method]antes de la prueba.


Eso ya me pasó a mí. Pero en esto ellos ese no es el caso.
miguelbgouveia
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.