unit-testing - unitarias - unit test c# ejemplo
Pruebas unitarias no descubiertas en Visual Studio 2017 (30)
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 comandos.
¿Alguien ha obtenido pruebas unitarias para ejecutar en VS 2017, si es 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 architectureestá establecida 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.
Descubrimiento
Las principales respuestas anteriores no funcionaron para mí (reiniciar, actualizar a la versión 1.1.18 ... Ya estaba actualizado, eliminando los archivos temporales, borrando el caché NuGet, etc.).
Lo que descubrí es que tenía diferentes referencias 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 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''s 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 obteniendo la versión de dotnet your en
$ dotnet --version
.
Si ve algo que no sea la última versión que ha instalado, entonces su máquina tiene algunos desajustes y no está utilizando la versión correcta.
Ejemplo ... Si tiene instalado dotnet core
1.0.1
pero cuando obtiene la versión en el símbolo del sistema y dice
1.0.0
eso 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
- Vea la publicación de blog @epestic donde brinda más detalles sobre cómo solucionar el problema.
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 desee.
¡No te olvides de construir tu proyecto!
A veces, descubro que si tiene excepciones de en su código de prueba de unidad, Visual Studio marcará ese caso de prueba de unidad como no ejecutado y dejará de ejecutar otros casos de prueba que siguen a este caso.
En este caso, debe averiguar qué caso está causando la excepción .
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.
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.
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.
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
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,
- Haga clic derecho en el proyecto y seleccione Descargar proyecto.
- Haga clic derecho en el proyecto y seleccione Editar
- Elimine la línea que importa la versión anterior del adaptador.
- Haga clic derecho en el proyecto y seleccione Recargar proyecto.
- Reconstruir solución / proyecto
En mi caso, el objetivo del proyecto de prueba es Arquitectura
x64
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 en
x64
y reconstruir todas las pruebas se descubrieron nuevamente.
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)
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.
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
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)
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.
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 encontró solo esos.
Instalé los paquetes del 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.
La API para los adaptadores de prueba para .NET Core cambió con el lanzamiento de Visual Studio 2017 y el cambio del formato
project.json
formato
csproj
.
Esto hizo que los adaptadores
dotnet-test-nunit
dotnet-test-*
como
dotnet-test-nunit
obsoletos.
Los adaptadores se han actualizado, pero la forma en que configura y ejecuta las pruebas en Visual Studio o en la línea de comandos con la
dotnet test
requiere referencias diferentes en sus proyectos de prueba.
Tenga cuidado con
cualquier documentación que encuentre que los paquetes de referencia están en formato
dotnet-test-*
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.Sdk
, su 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 pruebas unitarias 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
La solución fue eliminar mi archivo
app.config
de mi proyecto de prueba de unidad.
¡Las pruebas volverán a aparecer!
Este archivo hacía 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.
No lea artículos desactualizados bajo MSDN. Los materiales relevantes de .NET Core están 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 la unidad.
Olvidar 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 por 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
Modificar la clase de prueba para que sea público solucionó mi problema
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 de 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.
Para mí, cambiar el TargetFramework en el archivo
.csproj
del proyecto de
.csproj
de
<PropertyGroup>
<TargetFramework>netcoreapp2.0</TargetFramework>
</PropertyGroup>
a
<PropertyGroup>
<TargetFramework>net46</TargetFramework>
</PropertyGroup>
trabajó.
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.
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.
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é
Microsoft.VisualStudio.TestPlatform.TestFramework.Extensions
paquetes
Microsoft.VisualStudio.TestPlatform.TestFramework
y
Microsoft.VisualStudio.TestPlatform.TestFramework.Extensions
a una versión muy antigua (usando el administrador NuGet) y aparecieron los métodos de prueba.
Luego me actualicé a la última versión y todavía estaba allí.
Así que solo degrada y actualiza los paquetes.
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.
Tuve una solución heredada que regresaba de VS2010, pasando por VS2013, VS2015.
Ahora en VS2017 parece que los espacios de nombres para el atributo
[TestMethod]
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. Tal vez cambiar las referencias de ensamblaje para el antiguo proyecto de prueba también hubiera funcionado. Con la nueva referencia, VS2017 descubrió esas pruebas unitarias.
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.