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.

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:

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.

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

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.

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

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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)

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.

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

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.

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.

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.

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

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.

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)

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!

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.

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

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.

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

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)