¿Por qué el Visual Studio 2015/2017/2019 Test Runner no descubre mis pruebas xUnit v2?


173

ACTUALIZACIÓN: Agregar un 2019; El mecanismo de integración de descubrimiento / corredor es el mismo que para 2017 y 2015, por lo que las cosas clave que pueden salir mal son las mismas.


He leído por qué el corredor de xUnit no encuentra mis pruebas, lo que cubre las razones por las cuales xUnit nunca podría encontrar sus pruebas, pero mi problema es diferente: estoy seguro de que no hay nada sutil en mis pruebas; (han trabajado en otros entornos, esto parece ser solo mi máquina): el Visual Studio Test Runner en Visual Studio 2015 [Community Edition] simplemente no muestra ninguna de mis pruebas. No estoy haciendo nada remotamente emocionante; las pruebas se dirigen a xUnit.net v2 en el escritorio.

He buscado en la ventana Salida y no veo nada en Prueba en las pestañas Mostrar salida .



1
Es solo un posible problema, pero obviamente debe compilar el proyecto de prueba antes de que se muestre en el explorador de prueba.
Niklas Peter



Instalar Xunit.Runner.VisualStudio ha resuelto mi problema
Bendram

Respuestas:


210
  1. Elimine las excepciones de descubrimiento de sus consultas; vaya a la ventana de salida (Ctrl-Alt-O), luego cambie el resultado del menú desplegable (Shift-Alt-S) a Pruebas y asegúrese de que no haya excepciones de descubrimiento

  2. Prueba | Configuración de prueba | La arquitectura de procesador predeterminada puede ayudar si sus pruebas son específicas para x86 / x64 y el descubrimiento desencadena excepciones relacionadas con bittingness, es decir, no AnyCpu

  3. Como se sugiere en esta respuesta (votar si la técnica ayuda) ejecutar el corredor de la consola de escritorio ( instrucciones ) puede ser una buena verificación cruzada para eliminar otras posibilidades, por ejemplo, archivos de configuración destrozados:

    packages\xunit.runner.console.2.2.0\tools\xunit.console <tests.dll>

    NOTA El xunit.runner.consolepaquete está en desuso: cuando obtiene cosas que funcionan en VS, también podrá dotnet testejecutarlas en contextos de CI


Vaya a leer la documentación : es completa, actualizada, incluye información de solución de problemas y toma PR: -

Nota importante: si ya instaló xUnit.net Visual Studio Runner VSIX (extensión), primero debe desinstalarlo. El corredor de Visual Studio solo se distribuye a través de NuGet ahora. Para eliminarlo, vaya a Herramientas > Extensiones y actualizaciones . Desplácese hasta el final de la lista y, si xUnit.net está instalado, desinstálelo. Esto te obligará a reiniciar Visual Studio.

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 este 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).

Los siguientes pasos me funcionaron:

  1. (Solo si sospecha que hay un desorden grave en su máquina; en general, el caso más común es que la integración de Visual Studio simplemente todavía no está instalada)

    Haga lo DEL %TEMP%\VisualStudioTestExplorerExtensionsque le aconsejan: -

    PS> del $env:TEMP\VisualStudioTestExplorerExtensions

  2. Instale el paquete NuGet xunit.runner.visualstudioen todos los proyectos de prueba

    • Paquete:

      .paket\paket add nuget xunit.runner.visualstudio -i

      Debe terminar con lo siguiente en supaket.dependencies :

      nuget xunit.runner.visualstudio version_in_path: true

      Tenga en cuenta que el version_in_path: truebit es importante

    • Nuget: vaya a la consola del Administrador de paquetes (Alt-T, N, O) y

      Install-Package xunit.runner.visualstudio)

    Reconstruir para asegurarse de que xunit.runnertermina en el directorio de salida

  3. Cerrar Test Explorer <- este fue el bit que faltaba para mí

  4. Vuelva a abrir el Explorador de pruebas (Alt-S, W, T)

  5. Ejecutar todas las pruebas (Ctrl R, A)


12
"Cerrar Test Explorer <- este fue el punto que faltaba para mí" Este es el paso más importante que también me perdí y pasé 5 horas para resolverlo. Gracias, debería haber prestado atención a los pasos :)
Esen

1
el xunit VS runner estaba trabajando para mi sln. Sin embargo, había dejado de aparecer un día. Descubrí que no instalé el VS en ejecución, y estaba funcionando probablemente debido a la memoria caché, dejada por el otro sln que tiene instalado el corredor. Después de instalar el corredor, las cosas vuelven a funcionar bien. Así que no olvides instalar el corredor para cada sln.
ZZZ

1
Es increíble. Eliminar la carpeta que tenía otras tres carpetas vacías solucionó el problema.
t3chb0t

1
@martinJH Tengo una respuesta automática para eso (Vinculado en OP): - stackoverflow.com/questions/16214684/… ;) Sin revelar cómo descubrí eso
Ruben Bartelink

1
¡Cosas realmente extrañas, pero eliminar %TEMP%\VisualStudioTestExplorerExtensionsy reiniciar VS finalmente funcionó!
Hinrich

35

Tuve que cambiar la configuración de prueba después de cambiar la CPU de proyectos de prueba a x64. Luego, las pruebas se detectaron nuevamente.

Arquitectura


¿Vio un mensaje antes en la salida de descubrimiento de prueba?
Ruben Bartelink

No, no vi ningún error, me llevó un tiempo darme cuenta.
Max

hmm extraño (vea la parte superior de mi respuesta: explica dónde buscar; normalmente esto está marcado (aunque hay casos definitivos en los que simplemente no hay mensajes en ninguna parte))
Ruben Bartelink

Esto me lo arregló. No sé por qué esto ayuda, pero lo hace.
VSO

2
Tuve que limpiar -> reconstruir después de cambiar.
user2023861

32

Ninguna de las soluciones anteriores funcionó para mí (dotnetcore 1.1, VS2017). Esto es lo que lo solucionó:

  1. Agregar paquete NuGet Microsoft.TestPlatform.TestHost
  2. Agregar paquete NuGet Microsoft.NET.Test.Sdk

Esos son adicionales a estos paquetes que instalé antes:

  • xunit (2.3.0-beta1-build3642)
  • xunit.runner.visualstudio (2.3.0-beta1-build1309)

9
Esto me ayudó, me faltaba el paquete xunit.runner.visualstudio.
Ognjen Babic

Mi proyecto de prueba MS .NET 4.72 TestPlatform.TestHostsolo se necesita al migrar de VS 2017 a VS 2019.
ΩmegaMan

Esto lo resolvió para mí. En la ventana Salida, seleccione Pruebas del menú desplegable => vea el mensaje "Falta el mensaje TestHost".
datchung


14

Sigue estos pasos:

  1. Actualiza tu MsTest.TestAdapteryMsTest.TestFramework dll's desdenugget package manager .
  2. Limpia tu solución
  3. Construye tu solución.

1
¿Puedes abrir un clon de esta pregunta y responder por favor como lo he hecho? Este es sobre xUnit v2 y posterior. Incluso las respuestas de xUnit v1 no tienen cabida aquí. Puede vincularlo con un ver también en la parte superior de la pregunta, o puedo vincularlo en la pregunta
Ruben Bartelink

Esta solución funciona ... De lo contrario, cada vez que tenía que eliminar %TEMP%\VisualStudioTestExplorerExtensionsy todavía a veces tenía que ejecutar las pruebas desde la consola.
Venky

Estoy usando NUnit y resolví este problema actualizando NUnit3TestAdapter a la última versión a través de NuGet.
dpberry178

Gracias por esto, en mi caso, solo tuve que actualizar-paquete-reinstalar MSTest.TestAdapter y las pruebas fueron recogidas.
Rob

10

He estado luchando con esto toda la tarde mientras trabajaba con un proyecto ASP Core y xUnit 2.2.0. La solución para mí fue agregar una referencia aMicrosoft.DotNet.InternalAbstractions

Descubrí esto al intentar ejecutar el proyecto de prueba manualmente con el dotnet testque falló pero informó que InternalAbstractionsfaltaba. No vi este error en la ventana de salida de prueba cuando falló el descubrimiento automático. La única información que vi en la ventana de descubrimiento fue un código de retorno, que no significaba nada para mí en ese momento, pero en retrospectiva probablemente indicaba un error.


"pero informó un error útil" ... ¿cuál fue? Además, ¿puede verificar que definitivamente no figuraba en la ventana de errores de descubrimiento como se indica en el OP? ". ?
Ruben Bartelink

1
Vea la respuesta actualizada, publicaré la información del código de retorno más adelante en caso de que sea relevante.
Tom Makin el

9

Me ha sucedido un par de veces: cuando limpio el proyecto y lo construyo de nuevo, tiende a estar bien.


¿Algún mensaje revelador cuando mira en la ventana de salida con las Pruebas seleccionadas en el menú desplegable?
Ruben Bartelink

2
Ninguno en absoluto, solo dice No se encontraron pruebas
Liam

En mi caso, Test Explorer estaba colgando en una prueba fallida anteriormente. Si lo buscaba e intentaba hacer clic con el botón derecho -> Ejecutar o algo así, todo el VS se colgaría. Simplemente haciendo una limpieza y reconstrucción borró el estado de la prueba y solucionó el problema por mí.
Piedone

¿Puedo agregar que simplemente construir (es decir, F6) no ayudará, debe hacer clic derecho en la solución en VS Solution Explorer y hacer clic en Reconstruir solución.
Piedone

8

Asegúrese de que su clase de prueba sea pública .


eso se aborda explícitamente en la primera condición (enlace otra pregunta que cubre ese caso); este Q + A solo trata sobre la resolución de problemas de cómo normalmente las pruebas que funcionan en otros lugares no funcionan para alguien que ahora está en un entorno determinado. Para mí, esta respuesta simplemente confunde las cosas, ya que diluye ese distintivo.
Ruben Bartelink

1
Muchas gracias. Salvaste mi día.
hellouworld

7

La razón en mi caso fue que la compilación de destino no era la misma entre el depurador del proyecto y el corredor de prueba. Para unificar esos elementos:

  1. Prueba> Configuración de prueba> Arquitectura de procesador predeterminada. luego seleccione X64 o X86.
  2. Proyecto> (su proyecto) Propiedades> Compilación (pestaña)> destino de la plataforma.

Después de que sean idénticos, reconstruya su solución y luego le aparecerán métodos de prueba.


6

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í


Suena doloroso Gracias por compartir y espero que ayude a alguien algún día. Sin embargo, tengo que decir: no se me ocurre ninguna razón para que el nivel de información de depuración afecte el proceso de descubrimiento, así que solo puedo decir "No creo que eso haya sido lo que realmente disparó al oso". Esperemos estar equivocado aunque;)
Ruben Bartelink

@RubenBartelink está completamente de acuerdo con usted, es por eso que mencioné "solución" en una cita :) pero lo suficientemente extraño, funcionó de inmediato una vez que hice esto.
curiousBoy

Muchas gracias. Esta fue también la solución para mí :)
Babulaas

6

Estoy usando xUnit 2.2.0.

Mi problema fue que mi solución no pudo encontrar ciertos dlls y app.config intentaba resolverlos. El error no aparecía en la ventana de salida de prueba en Visual Studio.

Pude identificar el error cuando instalé xunit.runner.consolee intenté ejecutar las pruebas a través de la línea de comandos.

Cómo ejecutar pruebas de xunit en CLI .


5

Puedo proporcionar una solución para un caso extremo que encontré hace unos días. Sin embargo, no va a ser la solución que se ajuste a todos los escenarios descritos anteriormente, para el caso límite lo resolví.

Tuve el mismo problema con VS 2017 más reciente (versión 15.5.7) y XUnit 2.3.1. Se instaló el paquete xunit.runner.visualstudio, sin embargo, las pruebas no aparecieron en el explorador de pruebas incorporado de VisualStudio.

Estaba trabajando en un proyecto heredado dirigido a .NET Framework 4.5. Sin embargo, comenzando con la versión 2.2. XUnit no es compatible con marcos .NET inferiores a 4.5.2 (consulte las Notas de la versión - XUnit 2.2: 19 de febrero de 2017

Cambiar el marco de destino del proyecto de prueba a una versión> = 4.5.2 funcionó para mí. No tiene que cambiar la versión del proyecto que está probando, se trata solo del proyecto de prueba en sí.


5

Tuve el mismo problema con Visual Studio 2019. Acabo de instalar los siguientes paquetes NuGet y el problema se resolvió.

1) xUnit

2) xunit.runner.visualstudio

3) Microsoft.TestPlatform.TestHost

4) Microsoft.NET.Test.Sdk


3

Esto también puede deberse a que la casilla de verificación de compilación no está marcada para el proyecto de plataforma actual en la configuración de compilación. Haga clic en Construir | Administrador de configuración, luego asegúrese de que los proyectos de prueba tengan una marca en la columna de compilación para la plataforma que está utilizando (por ejemplo, 'x86').

Esta fue definitivamente la solución que funcionó para mí.


Votaría esto si estuviera en stackoverflow.com/questions/16214684/… ya que no es específico de xunit2 y es un buen elemento de lista de verificación
Ruben Bartelink

3

Asegúrese de no haber escrito sus pruebas unitarias en una biblioteca de clases .NET Standard 2.0. El visualstudio runner no admite la ejecución de pruebas en bibliotecas de clase netstandard2.0 en el momento de escribir este artículo.

Verifique aquí la matriz de compatibilidad de Test Runner:

https://xunit.github.io/#runners


3

Se encontró con un problema similar con VS no descubriendo métodos de prueba. En mi caso, tenía la palabra clave estática con el método, que eliminé y funcionó.

[TestMethod]

Before: public static void Test1()

After: public void Test1()

1
Realmente preferiría que esto no estuviera aquí, ya que se trata de pruebas correctas que no se pueden encontrar en una instancia particular de VS. Tengo una respuesta automática sobre por qué no se puede descubrir una prueba de xunit: stackoverflow.com/questions/16214684/… . ¿Puedo sugerirle que cree un por qué mi prueba MSTest no puede ser recogida (por VS si lo desea)? (Como probablemente sabe, esta preocupación particular ni siquiera se aplica a xUnit, que es otra razón por la cual, por útil que sea, su respuesta no pertenece aquí)
Ruben Bartelink

MSTest no encontró mis pruebas porque el modificador de acceso de clase era interno.
Abdul Saboor

3
  1. Cerrar todas las instancias de Visual Studio
  2. Vaya a% TEMP% \ VisualStudioTestExplorerExtensions \
  3. Eliminar carpetas relacionadas
  4. Inténtalo de nuevo

házmelo saber, gracias


2

En mi caso, tenía 2 proyectos de prueba diferentes en la solución. Las pruebas del Proyecto 1 se pudieron encontrar, pero las pruebas del Proyecto 2 no. Descubrí que primero al descargar la prueba del Proyecto 1, luego al cerrar VS> borrar mis archivos temporales> volver a abrir la solución> reconstruir, permití que VS descubriera mis pruebas del Proyecto 2.

Supongo que algo debe estar en conflicto entre los dos proyectos de prueba y esta fue la forma más rápida de ponerme en funcionamiento en unos minutos. Los problemas se pueden resolver más tarde :).


2

Sufrí de este problema durante mucho tiempo.

  • Tenía alrededor de 100 proyectos de diferentes versiones que se implementaron en diferentes servidores.

  • Actualizar xunit de 2.2.0 a 2.3.1 no fue una solución porque la compilación fallaba en 2.3.1.

Luego acabo de actualizar xunit.runner.visualstudio a 2.3.1 y todo comenzó a funcionar bien. He usado este comando en mi consola del administrador de paquetes para actualizar mi paquete xunit.runner.visualstudio

Get-Project ComapanyName.ProjectName.*.Tests | Install-Package xunit.runner.visualstudio -Version 2.3.1

1

El culpable más común para mí ha sido Visual Studio tratando de ejecutar las pruebas usando una arquitectura diferente a la biblioteca que está probando. Lamentablemente, hay varios lugares donde parece que esto puede salir mal.

En VS 2017, intente crear un archivo de Configuración de ejecución, por ejemplo, Default.runsettingsen su proyecto de prueba. Si su lib principal es x64, el contenido debe ser:

<?xml version="1.0" encoding="utf-8"?>
<RunSettings>
  <RunConfiguration>
    <TargetPlatform>x64</TargetPlatform>
  </RunConfiguration>
</RunSettings>

Luego elija este archivo de Prueba -> Configuración de prueba -> Seleccionar archivo de configuración de prueba.

Luego, en Prueba -> Configuración de prueba, Arquitectura de procesador predeterminada, elija nuevamente la arquitectura correcta.

Asegúrese de limpiar y construir la solución completa. Es posible que deba cerrar y volver a abrir la ventana Explorador de prueba. Busque cualquier error adicional en la ventana Salida -> Prueba, para obtener más pistas sobre tipos de arquitectura incorrectos.

Para su información, puede encontrar entradas adicionales de Configuración de prueba aquí .


1

Hay otra razón que puede hacer que Test Explorer no muestre ninguna prueba, y tiene que ver con el nuevo .pdbformato de archivo portátil introducido con Visual Studio 2017 / para .NET Core que puede romper algunas herramientas de VS. (Antecedentes: consulte el informe de error "Mono.Cecil causa OutOfMemoryException con los nuevos PDB de .csproj" ).

¿No se encuentran sus pruebas debido al nuevo .pdbformato portátil (símbolos de depuración)?

  • Abra la ventana de salida .
  • Cambiar la selección desplegable para Mostrar salida de a Pruebas .
  • Si ve resultados como los siguientes (posiblemente repetidos una vez para cada una de sus pruebas), entonces tiene el problema descrito en esta respuesta:

    Exception System.OutOfMemoryException, Exception converting <SignatureOfYourTestMethod>
    Array dimensions exceeded supported range.

En caso afirmativo, haga esto para resolver el problema:

  • Abra las Propiedades de su proyecto de prueba (seleccione el proyecto de prueba en el Explorador de soluciones y presione Alt+ Enter).
  • Cambiar a la compilación pestaña .
  • Haga clic en Avanzado ... botón (ubicado al final de la página de esa pestaña).
  • En la etiqueta hacia abajo y soltar información de depuración , elija none, pdb-onlyo full, pero NO portable . Es esta última configuración la que hace que no se encuentren las pruebas.
  • Haga clic en Aceptar y limpie y reconstruya su proyecto. Si desea estar más seguro, vaya al directorio de salida de su proyecto de prueba y limpie todos los .pdbarchivos antes de reconstruir. Ahora tus pruebas deberían estar de vuelta.

1

Me sucedió cuando hice mis primeros intentos de caminar con IntelliTest en VS 2017.

A veces, cuando IntelliTest crea automáticamente el proyecto de prueba, la referencia del ensamblaje a Microsoft.ExtendedReflection( ... \ Archivos de programa (x86) \ Microsoft Visual Studio \ 2017 \ Enterprise \ Common7 \ IDE \ Extensions \ Microsoft \ Pex \ Microsoft.ExtendedReflection. dll ) no se encuentra. Cuando se agrega, las pruebas generadas se mostrarán en el explorador de pruebas después de la compilación.


1

Descargo de responsabilidad: no se trata de xunit con Visual Studio 2015, sino de Visual Studio 2017 con una aplicación de prueba de unidad UWP (MSTest). Llegué a este hilo buscando lo mismo, así que tal vez alguien más haga lo mismo :)

La solución para mí fue actualizar los paquetes nuget para MSTest.TestAdapter y MSTest.TestFramework. Parece que cuando crea una aplicación de prueba unitaria para UWP no obtiene automáticamente las últimas versiones.


Sugeriría hacer una pregunta con respuesta propia como lo hice es la mejor manera de secuestrar dicha información: siéntase libre de copiar y pegar toda mi pregunta y s / xUnit / MSTest / si cree que tiene sentido;)
Ruben Bartelink

1

Mi problema se resolvió instalando el nuget xunit.runner.visualstudio


1

En mi caso, tengo varios proyectos de prueba en la misma solución, y solo uno de los proyectos no mostraba el "Explorador de pruebas"

Fui al "Gestionar paquete Nuget para la solución" haciendo clic derecho en la solución.

Noté que debajo de la pestaña "Consolidar" había algunos paquetes nuget de "Prueba" que no estaban sincronizados entre los proyectos. Hice clic en "Instalar" y aparecieron mis pruebas faltantes.


1

Intenté la mayoría de las sugerencias anteriores y nada funcionó. En mi caso, estoy en un equipo y aparecían pruebas para otros desarrolladores para la misma solución. Entonces, intenté eliminar mi carpeta .vs, pero tampoco tuve suerte.

Terminé eliminando mi carpeta local por completo y volviendo a clonar el repositorio. Eso lo resolvió para mí.


1

Aquí está la solución que funcionó para nosotros. No es el mejor, pero quizás uno pueda beneficiarse.

Antecedentes:

  • Nuestros scripts se desarrollaron con VS 2013 y utilizaron NUnit VS Adapter 2.1 ..
  • Recientemente migramos a VS 2017 y cuando abrimos la misma solución, la prueba no se mostraría en el Explorador de pruebas

En Build veríamos este mensaje:

[Informational] NUnit Adapter 3.10.0.21: Test discovery starting
[Informational] Assembly contains no NUnit 3.0 tests: C:\ihealautomatedTests\SeleniumTest\bin\x86\Debug\SeleniumTest.dll
[Informational] NUnit Adapter 3.10.0.21: Test discovery complete

Solución (temporal):

  • Desinstalar el adaptador NUnit 3.10 ...
  • Instale NUnit VS Adapter 2.1 ..

Ahora se muestran las pruebas.


Extraiga su (al menos aparentemente) nueva pregunta en su propia publicación para que sea una respuesta clara :)
geisterfurz007

... Titulado "¿por qué el NUnit TestAdapter v3 no ve mis pruebas de NUnit v2? Y a) hace ping aquí b) y pone un" see also <link> "en la parte superior (incluso si es un poco tenue), pero como esta respuesta eliminada ya que no encaja bien con xUnit v2 testsel título.
Ruben Bartelink

0

También verifique si hay un archivo app.config completamente vacío (completamente en blanco sin absolutamente ningún marcado) dentro del proyecto de prueba. Este fue el culpable en mi caso.


0

En mi caso, creé una nueva "Configuración de la solución" como se muestra en la imagen. Entonces, cuando selecciono mi personalizado como "Prod", no reconoce TestMehods por alguna razón. Cambiar de nuevo a "Depurar" resuelve el problema

ingrese la descripción de la imagen aquí


0

No sé si algunos de ustedes también usan JustMock, pero tuve que deshabilitar el generador de perfiles en VS 2017 para que funcione la detección de pruebas.


Hmmm Si lo vuelve a encender, ¿vuelve a fallar inmediatamente?
Ruben Bartelink

Sí. Si cierro la solución, enciendo el generador de perfiles y vuelvo a entrar, la detección de prueba falla.
chrisdrobison
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.