Pruebas unitarias no descubiertas en Visual Studio 2017


213

He estado luchando con VS 2017 desde que lo instalé. Ahora parece que las pruebas unitarias solo se ejecutarán desde la línea de comandos "prueba dotnet".

Mi proyecto es .NET Core 1.1.1. Tengo instalado el SDK y la actualización del marco para 1.1.1.

He probado la muestra en MSDN ( https://msdn.microsoft.com/en-us/library/ms182532.aspx ) que también falla exactamente de la misma manera.

Todos los paquetes de NuGet para las pruebas y el proyecto principal son actuales. Y tanto el proyecto de prueba como el proyecto principal se construyen sin errores. Y las pruebas se ejecutan con éxito desde la línea de comando.

¿Alguien ha conseguido que se realicen pruebas unitarias en VS 2017? De ser así, ¿cómo?

Gracias John


Actualización - Extender

Aquí hay un ejemplo de un proyecto de prueba simple que no funciona en GitHub . Este es un ejemplo con xUnit, pero he probado NUnit y visual studio integrado en pruebas de MS. No importa qué pruebas o qué cambios realice, no puedo hacer que el corredor de pruebas VS encuentre ninguna prueba.

Lo que he probado

  • Eliminar archivos de caché de prueba VS DEL %TEMP%\VisualStudioTestExplorerExtensions
  • Reiniciar VS
  • Explorador de prueba de cierre / apertura
  • para xUnit instalado Microsoft.DotNet.InternalAbstractions( ver publicación SO )
  • para NUnit, asegúrese de que el adaptador esté instalado y la misma versión (3) que el paquete NUnit
  • test -> test settings -> default processor architecture se establece en x86

La pregunta
¿Alguien puede proporcionar un ejemplo funcional de una solución .Net Core 1.1.0 en VS2017 (archivos de proyecto .csproj) donde el explorador de pruebas VS encuentra con éxito las pruebas unitarias O me muestra el problema en el ejemplo dado.


Descubrí que VS2017 no instala todos los paquetes necesarios. Cuando intenté mover mi MonoGame de una PC vieja a una nueva con Windows 10 y VS 2017 recién instalados, comencé a arrojar errores extraños sobre paquetes faltantes. Después de instalar VS2015 junto con VS2017, todos los problemas desaparecieron. Quizás intente instalar VS2015 adicionalmente.
Mateusz

2
Intente instalar paquetes de pruebas con el instalador de Visual Studio
Markiian Benovskyi

Estoy investigando si VS 2017 tiene todas las variables de entorno establecidas correctamente.
John Pezzanite

1
Para NUnit, debe usar el paquete NuGet para el adaptador y debe ser 3.8.0-alpha1 o más reciente.
Rob Prouse

2
En mi caso, fue la mera presencia de un app.configarchivo en mi proyecto de prueba: stackoverflow.com/a/47497668/67824 .
Ohad Schneider

Respuestas:


189

En mi caso, resultó que simplemente tenía que actualizar mis adaptadores de prueba y el marco de prueba. Hecho.

Ejemplo usando el Administrador de paquetes NuGet:

ingrese la descripción de la imagen aquí


44
¡Esto también me ayudó! Tenga en cuenta que puede "Administrar paquetes Nuget" a nivel de solución y hacer esto para todos los proyectos donde sea necesario. Es posible que obtenga errores de "referencia ambigua": para estos, simplemente elimine la antigua DLL (Microsoft.VisualStudio.QualityTools.UnitTestFramework) de las referencias
Prashanth Subramanian

48
Estas cosas deberían ser extensiones de Visual Studio, no paquetes NuGet.
Jaider

1
Tenemos muchos proyectos antiguos de MSTest, y no sabía que se movió a un paquete NuGet. Esto también me resolvió, originalmente pensé que era un error con las nuevas versiones de ReSharper hasta que me di cuenta de que VS Test Explorer tampoco podía descubrir mis pruebas.
David Anderson el

1
Hice exactamente lo mismo que dice esta respuesta. En mi solución VS2017, agregué un proyecto MSTest, agregué algunas pruebas, pero construir la solución resultaría en: Prueba de descubrimiento finalizada: 0 encontrado. Entonces, para el proyecto de prueba, en NuGet Package Manager (también puede hacerlo a nivel de solución), actualicé MSTest.TestAdapter y MSTest.TestFramework, ambos de v1.1.18 a v1.2.0. Luego, después de hacer una compilación, mis pruebas ahora aparecen en Test Explorer.
Kershaw

1
Funcionó muy bien para mí. Tuve que ingresar al administrador de paquetes nuget en VS2017 para el proyecto de prueba en particular y simplemente actualicé los diversos paquetes que tenía como nunit, etc., luego construí> reconstruir y todo estuvo bien.
Tahir Khalid

126

Esto simplemente funcionó para mí (no sé si es el resultado del cambio de espacios de trabajo que corrompió algo):

Eliminar archivos de caché de prueba VS en% TEMP% \ VisualStudioTestExplorerExtensions y reiniciar VS2017.


44
Esto funcionó una vez, no después. Lo que (esta vez) lo arregló para mí fue eliminar la carpeta TestResults y bin / obj (junto con esta limpieza del directorio temporal)
icesar

24
Cualquiera que se pregunte dónde %TEMP%: traer ventana de comandos y escribirecho %TEMP%
mike123

21
La carpeta no existe en temp: /
Douglas Gaskell

Entonces, ¿cuál es la causa de tal comportamiento?
Mykhailo Seniutovych

1
La forma más fácil de acceder a% TEMP% es ganar + R y escribir% TEMP%
PontiusTheBarbarian

58

La API para los adaptadores de prueba para .NET Core cambió con el lanzamiento de Visual Studio 2017 y el cambio del project.jsonformato al csprojformato. Esto hizo que los dotnet-test-*adaptadores existentes dotnet-test-nunitquedaran obsoletos.

Los adaptadores se han actualizado, pero la forma en que configura y ejecuta pruebas en Visual Studio o en la línea de comandos dotnet testrequiere diferentes referencias en sus proyectos de prueba. Tenga cuidado con cualquier documentación que encuentre que los paquetes de referencia están en el dotnet-test-*formato porque están desactualizados.

Primero, su proyecto de prueba debe apuntar a una plataforma específica, ya sea .NET Core o .NET Framework. No puede apuntar a .NET Standard incluso si el código que está probando es .NET Standard. Esto se debe a que el objetivo de las pruebas indica en qué plataforma ejecutar las pruebas. .NET Standard es como una PCL (Biblioteca de clases portátil) en el sentido de que puede ejecutarse en muchas plataformas.

A continuación, debe agregar referencias a Microsoft.NET.Test.Sdksu marco de prueba de elección y un adaptador de prueba compatible. Para NUnit, sus referencias se verán así,

<itemgroup>
    <packagereference Include="Microsoft.NET.Test.Sdk" Version="15.0.0"></packagereference>
    <packagereference Include="NUnit" Version="3.7.1"></packagereference>
    <packagereference Include="NUnit3TestAdapter" Version="3.8.0"></packagereference>
</itemgroup>

Un comentario anterior menciona agregar,

<ItemGroup>
    <Service Include="{82a7f48d-3b50-4b1e-b82e-3ada8210c358}" />
</ItemGroup>

Esto no es estrictamente necesario, pero puede ayudar. Visual Studio lo agrega automáticamente a todos los proyectos de prueba unitaria para ayudarlo a encontrar rápidamente proyectos con pruebas.

Si sus pruebas no aparecen en Visual Studio, lo primero que debe intentar es cerrar su solución y luego volver a abrirlas. Parece que hay errores en Visual Studio que no detectan cambios en los proyectos cuando los edita.

Para obtener más información, consulte Prueba de .NET Core con NUnit en Visual Studio 2017


2
Apuntar a .NET Framework en lugar de .NET Standard funcionó para mí. Gracias.
Ben Griswold

77
Esa referencia de Microsoft.NET.Test.SDK faltaba en mi proyecto y no había ninguna indicación en ningún lugar de que algo dependiera de ella para mostrar. Lo agregó a través de la consola nuget y todo comenzó a funcionar. Gracias por el listado de referencia!
GWhite

Tuve que copiar esta carpeta de un compañero de trabajo a mi directorio temporal y reiniciar VS:% TEMP% \ VisualStudioTestExplorerExtensions \ MSTest.TestAdapter.1.1.18
Heiner

¿Cómo puedo probar un proyecto netstandard 2.0 si cambio mi Marco de destino? No puedo compilar más porque un proyecto netstandard2.0 no puede ser referenciado por un proyecto que tagets net46
Jerome2606

1
Esto funcionó para mí. Gracias por la solución detallada.
Talha Ashfaque

42

Tuve el mismo problema y lo hice funcionar haciendo lo siguiente ...:

  • Primero cierre todas las instancias abiertas de Visual Studio y elimine esta carpeta:% TEMP% \ VisualStudioTestExplorerExtensions. ( Ejecución de pruebas con Visual Studio )
  • Vaya a su administrador de paquetes Nuget e instale Microsoft.NET.Test.Sdk (15.3.0-preview-20170425-07) primero y luego instale xunit.runner.visualstudio (2.3.0-beta1-build1309). Vea la captura de pantalla adjunta de Nuget para ver todos los paquetes que tuve que instalar para obtener el último VS 2017 para detectar mis pruebas.Captura de pantalla de Nuget

35
Eliminar % Temp% \ VisualStudioTestExplorerExtensions fue suficiente para mí.
Juan Pablo Gómez

Yeap Simplemente eliminar eso y reiniciar VS lo arregló.
Juan Carlos

¿Alguien sabe qué causa esto en primer lugar? Me ha sucedido dos veces, pero eliminar esa carpeta y reiniciar VS funcionó. Es raro
RubyHaus

@PmanAce: lo hice, en realidad. Estoy usando dos instancias TFS diferentes (una por proyecto), por lo que el espacio de trabajo cambia automáticamente cuando cambio de proyecto.
RubyHaus

eliminar la carpeta y agregar el nuget Microsoft.NET.Test.Sdkparecía funcionar para mí ... gracias StackOverflow. (Solución .NET Framework WebApi 2)
bkwdesign

40

Olvidando hacer pública la clase de prueba evita que se descubran los métodos de prueba en el interior

Tenía un proyecto xUnit predeterminado y eliminé el ejemplo UnitTest1.cs, reemplazándolo con una clase de prueba de controlador, con un par de pruebas, pero no se encontró ninguna.

En pocas palabras, después de actualizar los paquetes xUnit, Test.Sdk, xUnit.runner y reconstruir el proyecto, encontré un error de compilación:

Error xUnit1000 Las clases de prueba deben ser públicas

Afortunadamente, la versión actualizada arrojó esta excepción para evitarme algunos problemas

La modificación de la clase de prueba para que sea pública solucionó mi problema


66
No estoy seguro de por qué votó en contra, pero antes de mi café de la mañana 100%, esto fue pasado por alto por mí.
Andrei

1
¡Intenté todas las otras respuestas a esta pregunta / problema y esta fue la que finalmente funcionó!
FastTrack

3
Ese es increíblemente embarazoso pero ... lo que sea. Lo gracioso es que si crea un caso de conjunto de pruebas en VS2017, no generará la publicclase, sino solo la clase, por lo que no lo descubrirá hasta que agregue el publicidentificador.
briosheje

por supuesto. my bad - mstest debería tener esta característica.
Crismograma

10

En mi caso, apunto el proyecto de prueba a x64Arquitectura y la configuración de prueba Arquitectura (prueba-> Arquitectura de procesador predeterminada) se configuró en x86. No coincidieron.

Después de volver a configurar la arquitectura de prueba x64y reconstruir todas las pruebas se descubrieron nuevamente.


en vs2017 la configuración desde el menú Prueba -> Configuración de prueba -> Arquitectura de procesador predeterminada
IcyBrk

8

Tuve problemas con VS 2017 para encontrar mi UnitTest también. No era el problema exacto que John estaba preguntando, pero este fue el primer resultado en Google que busqué, así que quería compartir mi problema.

Tenía una solución heredada que regresaba de VS2010 y que revisaba VS2013, VS2015. Ahora en VS2017 parece que los espacios de nombres para el [TestMethod]atributo han cambiado.

Antes de usar

Microsoft.VisualStudio.QualityTools.UnitTestFramework, Version=10.0.0.0

Creé un nuevo Test.dll en el proyecto y el que usé por defecto

Microsoft.VisualStudio.TestPlatform.TestFramework, Version=14.0.0.0

Entonces, mi solución fue crear un nuevo proyecto UnitTest desde VS2017. Quizás cambiar las referencias de ensamblaje para el antiguo proyecto de prueba hubiera funcionado también. Con la nueva referencia, VS2017 descubrió esas pruebas unitarias.


Lamentablemente, incluso un nuevo proyecto de prueba de unidad no tiene su prueba para mí: /
Douglas Gaskell

7

No lea artículos desactualizados bajo MSDN. Los materiales relevantes de .NET Core se encuentran en docs.microsoft.com

https://docs.microsoft.com/en-us/dotnet/articles/core/testing/

En términos generales, necesita una aplicación de consola .NET Core para contener los casos de prueba de unidad.


Muchas gracias, Lex. Si este artículo es correcto, la única forma de probar .NET Core es desde la línea de comandos, perdiendo así toda la integración de VS que tuvimos con la ejecución de pruebas en VS 2015. ¿Estoy en lo correcto?
John Pezzanite

¿Usas xUnit.net o MSTest?
Lex Li

@JohnPezzanite tienes que mostrar más de lo que hiciste (probablemente un repositorio de GitHub si es posible). Tengo proyectos en GitHub que funcionan perfectamente, y muchos otros también.
Lex Li

Siga el ejemplo en la línea que proporcioné. Lo probé con .NET estándar y .NET Core, con las pruebas unitarias de Microsoft como en el ejemplo y con xUnit. El estándar .NET se integra con VS 2017, mientras que .NET Core solo se ejecutará desde la línea de comandos. Pero estoy repitiendo lo que he dicho anteriormente. Parece que Microsoft ha eliminado todo el formulario de integración de prueba de unidad .NET Core VS 2017.
John Pezzanite

@JohnPezzanite prueba GitHub.com/lextm/sharpsnmplib y su solución NetStandard.
Lex Li

6

para mí el problema fue que coloqué por error los casos de prueba en una clase interna

[TestClass]
  internal class TestLib {
}

eso estaba causando que no se identificaran casos de prueba.


5

Asegúrese de estar utilizando el Microsoft.NET.Test.Sdk correcto:

<PackageReference Include="Microsoft.NET.Test.Sdk" Version="15.0.0" />

No utilice uno de prelanzamiento. O tiene que cambiar a la aplicación de consola (no a la biblioteca). Tengo el problema similar, pero con la última versión (15.0.0) comienza a funcionar nuevamente.

Además, es posible que deba agregar:

  <ItemGroup>
    <Service Include="{82a7f48d-3b50-4b1e-b82e-3ada8210c358}" />
  </ItemGroup>

pero no creo que sea necesario.


¿En qué archivo se encuentra esto? Puedo encontrar la parte "Servicio incluido" en el archivo de mi proyecto (* .csproj) pero no en PackageReference.
Chris Bennet

@ChrisBennet en su archivo * test.csproj.
Evgeni Nabokov

1
@ evgeni-nabokov tiene razón. Todos estos cambios están en el archivo [proyecto] .test.csproj. Haga clic derecho en el proyecto en solución y seleccione "Editar [proyecto] .test.csproj". Vea el ejemplo en: github.com/RenetConsulting/angularcore.net/blob/master/Business/…
Alex Altotsky

5

Sé que OP lo ha incluido en su lista de verificación, pero es fácil pasar por alto ese punto al realizar una instalación limpia de Visual Studio 2017 y configurar un nuevo proyecto. Además de la plantilla de proyecto NUnit y NUnit Framework, uno necesita instalar el adaptador NUnit por separado, por ejemplo, usando el comando NuGet Install-Package NUnit3TestAdapter -Version 3.9.0. Después de eso, Visual Studio Community 2017 comenzó a descubrir pruebas unitarias sin ningún problema.


1
Esto me ayudó!
YvesR

Dios mío, este lo hizo por mí. Si pudiera empaparte de recompensas, lo haría.
Ash

Esta fue la única solución que funcionó para mí, ¡gracias!
Vadim Tofan

5

En mi caso, el Explorador de pruebas no pudo encontrar mis pruebas después de que moví el proyecto a una nueva solución.

La respuesta fue simplemente que tenía una referencia al antiguo adaptador de prueba de MS en mi proyecto.

Tenía un duplicado de la línea a continuación para la versión 1.1.11 del Adaptador de prueba de MS en mi archivo cs.proj:

<Import Project="..\packages\MSTest.TestAdapter.1.1.18\build\net45\MSTest.TestAdapter.props" Condition="Exists('..\packages\MSTest.TestAdapter.1.1.18\build\net45\MSTest.TestAdapter.props')" />

Para solucionar el problema,

  1. Haga clic derecho en el proyecto y seleccione 'Descargar proyecto'.
  2. Haga clic derecho en el proyecto y seleccione 'Editar'
  3. Elimine la línea que importa la versión anterior del adaptador.
  4. Haga clic derecho en el proyecto y seleccione 'Recargar proyecto'.
  5. Reconstruir solución / proyecto

Tuve el mismo problema. La solución de eliminación y reconstrucción no funcionó. ¡Se reiniciaron VS y se descubrieron pruebas!
Mike Ward

4

Acabo de tener este problema con Visual Studio al no poder encontrar mis pruebas, no podía ver el botón para ejecutarlas además del método, y no se detectaron al ejecutar todas las pruebas en el proyecto.

¡Resulta que mi clase de prueba no era pública! Hacerlo público permitió a VS descubrir las pruebas.


2

Para mí fue más fácil crear un nuevo proyecto de prueba que funciona perfectamente con Visual Studio 2017 ... y simplemente copiar los archivos de prueba, agregar referencias y paquetes NuGet según sea necesario.

ingrese la descripción de la imagen aquí


¡Crear un nuevo proyecto probablemente ahorró horas de dolor de cabeza!
M.kazem Akhgary

2

En mi caso, era un proyecto que había actualizado el proyecto de prueba de una versión anterior de .Net. en la app.config tuve enlaces de ensamblaje a versiones anteriores de los ensamblajes dependientes.

Después de arreglar los enlaces de ensamblaje en app.config, se descubrieron mis pruebas.


2

Descubrimiento

Las principales respuestas anteriores no funcionaron para mí (reiniciar, actualizar a la versión 1.1.18 ... ya estaba actualizado, eliminar los archivos temporales, borrar la memoria caché de NuGet, etc.).

Lo que descubrí es que tenía referencias diferentes a MSTest.TestAdapter y MSTest.Framework en diferentes proyectos de prueba (mi solución tiene dos). Uno señaló 1.1.18 como ...

paquetes.config

<package id="MSTest.TestAdapter" version="1.1.18" targetFramework="net461" />
<package id="MSTest.TestFramework" version="1.1.18" targetFramework="net461" />

... pero otro tiene las referencias a 1.1.11. Algunas de las respuestas anteriores conducen a este descubrimiento cuando aparecieron dos versiones de las bibliotecas en mi directorio temporal (% TEMP% \ VisualStudioTestExplorerExtensions \) después de reiniciar Visual Studio.

Solución

Simplemente actualizar my packages.config a la versión 1.1.18 es lo que restauró la funcionalidad de las pruebas de mi unidad en VS. Parece que hay algunos errores que no permiten referencias en paralelo de las bibliotecas MSTest. Espero que esto te ayude.

Más información:

  • Visual Studio 2017 Ent: 15.5.6 (había actualizado desde 15.0.1 con la esperanza de solucionar este problema, pero lo tenía en ambos)

2

La solución estaba eliminando mi app.config archivo de mi proyecto de prueba de unidad. ¡Las pruebas volverán a aparecer!

Este archivo hace referencia a algunos dll en los enlaces vinculantes que en realidad no estaban presentes en las referencias del proyecto. Vuelva a agregar los enlaces de ensamblaje que son estrictamente necesarios para su proyecto.


1

En mi caso, fue el proyecto UWP presente en la solución el que causó el problema.

Cuando descargué el proyecto UWP, se descubrieron pruebas. Cuando lo cargué de nuevo, la prueba desapareció nuevamente.

Intente descargar todos los proyectos y mantenga solo el proyecto de prueba. Diez soluciones de reconstrucción y shound de prueba aparecen en Test Runner. Cargue proyectos uno por uno y reconstruya la solución cada vez para descubrir qué proyecto está causando el problema

repositorio de muestra

Informe de error VS


Agradezco la respuesta, pero este no es mi problema. Si miras el repositorio de ejemplo al que he vinculado en mi pregunta, solo hay un único proyecto en la solución. No hay otros proyectos para eliminar. Sin embargo, esa solución es una prueba, así que probé lo que dijiste descargando proyectos en mi solución real, pero no funcionó.
rayepps

1

La cuestión

El problema es que Visual Studio se está "confundiendo" con las versiones centrales de dotnet en la máquina. Cuando fui al panel de control -> desinstalar programas, tenía 8 dotnet core SDK y Runtimes diferentes instalados. Esto de alguna manera estaba causando que VS tuviera un error silencioso al intentar encontrar pruebas.

Validar el problema

Puede validar el problema yendo a la línea de comando y activando la versión de dotnet $ dotnet --version. Si ve algo que no sea la última versión que ha instalado, entonces su máquina no coincide y no está utilizando la versión correcta. Ejemplo ... Si tiene 1.0.1instalado dotnet core pero cuando obtiene la versión en el símbolo del sistema y dice1.0.0 es un problema.

La solución

Eliminar todas las cosas viejas. Comencé solo con lo que necesitaba eliminar (las versiones más antiguas de dotnet rc) pero aún así me dio la versión incorrecta al probar el problema. Finalmente admití hacer una limpieza completa. YO...

  • Desinstaló todas las aplicaciones de Visual Studio (en mi máquina VS2015 y VS2017)
  • Desinstaló todas las versiones de dotnet core (incluso la más reciente)

Después de que mi máquina estaba completamente vacía de todos los VS y terminé, instalé solo VS2017 (viene empaquetado con la última dotnet). Creé un proyecto de prueba xUnit y el explorador de pruebas encontró la prueba inmediatamente RESUELTA

Esto puede parecer una exageración, pero pasé dos semanas tratando de arreglar esto de otras maneras. Si tiene el problema, hágalo, aunque puede llevarle horas desinstalar / reinstalar elementos, probablemente le ahorrará tiempo.

Referencias

  • Consulte la publicación de blog @epestic donde brinda más detalles sobre cómo solucionar el problema.

1

He intentado todo pero nada ha ayudado. En mi caso, tenía una solución con varios proyectos de prueba y algunos de ellos usaban el antiguo marco de prueba de ms, por lo que Visual Studio solo encontró esos.

Instalé los paquetes de marco de prueba para todos los proyectos de prueba como se muestra en la respuesta aceptada . Luego eliminé las referencias a las viejas herramientas de calidad, reinicié Visual Studio y ahora puedo ver todas las pruebas.


1

Para C ++:

Como no hay una pregunta especial para las pruebas de C ++, pero el tema es muy similar, esto es lo que me ayudó cuando tuve problemas con el descubrimiento de pruebas.

Si solo instaló el desarrollo de escritorio con C ++ , entonces la solución es instalar también el desarrollo de la Plataforma universal de Windows con las herramientas opcionales de la Plataforma universal de Windows C ++ . Puede seleccionarlos en el instalador web de Visual Studio.

Luego, reconstruya su proyecto de prueba y el descubrimiento de prueba debería funcionar.

Por cierto, creé el proyecto de prueba de unidad en VS2017. Puede ser importante, porque algunos usuarios mencionaron, que tenían problemas de descubrimiento en proyectos, que se migraron de VS2015 a VS2017.


1

Eliminar el viejo .dll debería ayudar. Borrar archivos temporales ubicados en el directorio% TEMP% en C: \ Users (su nombre de usuario) \ AppData \ Local \ Temp


1

Tuve el mismo problema. Mi solución estaba bien, pero de repente cuando abrí la solución descubrí que las pruebas habían desaparecido.

Finalmente bajé de categoría Microsoft.VisualStudio.TestPlatform.TestFrameworky Microsoft.VisualStudio.TestPlatform.TestFramework.Extensionsempaqué a una versión muy antigua (usando el administrador NuGet) y aparecieron los métodos de prueba. Luego actualicé a la última versión y todavía estaba allí.

Así que solo degrada y actualiza los paquetes.


1

En mi caso, ninguno de los anteriores me ayuda. Pero, degrado NUNit3TestAdapter a la versión 3.8.0, luego actualizo a la última (3.10.0)


1

A veces, cambiar el espacio de nombres de las pruebas funciona. Tenía la estructura de carpetas de la siguiente manera:

A |___B | |___D |___C___E

El espacio de nombres era plano como Pruebas. <Nombre> y no aparecían en la ventana de prueba. Cuando cambié el espacio de nombres a la estructura del directorio, aparecieron todas las pruebas. Ahora podría volver a cualquier otra estructura de espacio de nombres que quiera.

¡No olvides construir tu proyecto!


1

En el caso de .NET Framework, en el proyecto de prueba anteriormente había referencias a las siguientes DLL:

Microsoft.VisualStudio.TestPlatform.TestFramework
Microsoft.VisualStudio.TestPlatform.TestFramework.Extentions

Los eliminé y agregué referencia a:

Microsoft.VisualStudio.QualityTools.UnitTestFramework

Y luego aparecieron todas las pruebas y comenzaron a funcionar de la misma manera que antes.

Intenté casi todas las otras sugerencias anteriores antes, pero simplemente volver a hacer referencia a las DLL de prueba funcionó bien. Publiqué esta respuesta para aquellos que están en mi caso.


1

Estaba enfrentando el mismo problema, en mi caso, para resolver

  1. Abrí la consola de Windows (tecla de Windows + cmd).
  2. Navegue a la carpeta donde se creó el proyecto.
  3. Ejecutado el comando "dotnet test", es básicamente la misma prueba que ejecuta Visual Studio, pero cuando lo ejecuta a través de la consola, le permite ver el rastro completo.
  4. Recibí este mensaje de error "Atributo TestClass definido en la clase no pública MSTest.TestController.BaseTest"
  5. Así que fui al caso de prueba y lo marqué como público, construí de nuevo y mis pruebas se muestran correctamente

0

Al principio, intenté usar MSTest. Después de eso, lo cambio a prueba de Nunit. Entonces quise respaldar MSTest. Eliminé todos los códigos y referencias de nUnit, pero Test Explorer no mostró los métodos MSTest. Solución: eliminé todas las referencias nuget de mstest y las reinstalé. Hecho.


0

Para mí, cambiar el TargetFramework en el .csprojarchivo del proyecto de prueba de

  <PropertyGroup>
    <TargetFramework>netcoreapp2.0</TargetFramework>
  </PropertyGroup>

a

  <PropertyGroup>
    <TargetFramework>net46</TargetFramework>
  </PropertyGroup>

trabajó.


0

En mi caso, el problema fue que el tipo de proyecto se configuró en una biblioteca estática (lib), y debería ser una biblioteca dinámica (dll)

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.