No se encontró ninguna prueba. Asegúrese de que los descubridores y ejecutores de prueba instalados, la plataforma y la configuración de la versión del marco sean los adecuados y vuelva a intentarlo

95

Estoy en el proceso de actualizar nuestra solución existente a .Net 4.6.1 y no he podido ejecutar nuestras pruebas unitarias durante la compilación del servidor. Localmente, se ejecutan como se esperaba y voltear la versión del marco de nuevo a .Net 4.5.1 hace que se ejecuten nuevamente en el servidor.

Estoy teniendo el siguiente error:

No se encontró ninguna prueba. Asegúrese de que los descubridores y ejecutores de pruebas instalados, la plataforma y la configuración de la versión del marco sean los adecuados y vuelva a intentarlo.

He reproducido el problema en una configuración más simple:

  • Solución con un solo proyecto de prueba unitaria de C # con dos pruebas (una que falla y otra que pasa).
  • Definición de compilación XAML con la plantilla predeterminada (TfvcTemplate.12.xaml)
  • Servidor de compilación XAML de TFS 2015 Update 1 con Visual Studio Enterprise 2015 Update 1 instalado (tiene seis servidores similares y todos producen el mismo resultado)
Tore Østergaard
fuente
Según Brian Harry de Microsoft, este es un error que están investigando actualmente. Debería corregirse en la Actualización 2 y debería publicarse una solución temporal más adelante. Fuente: enlace
Tore Østergaard
Tengo el mismo problema para .Net 3.5 SP1 en Visual Studio 2013 Update 5.
Andrey Bushman
@AndreyBushman: El error también podría estar en 2013U5, ya que se lanzó junto con 2015RTM. Pero la solución alternativa también debería funcionar en su caso.
Tore Østergaard
Tuve un problema similar, la solución fue simplemente en vs, bajo la configuración de prueba, para seleccionar el bit del procesador predeterminado correcto (32/64) y no mantener el motor en funcionamiento. (vs 2017.x)
kfn

Respuestas:

59

Puede intentar cambiar la arquitectura de su procesador predeterminado en su configuración de prueba de X86 a X64. En mi caso este fue el problema.

Esto sucede si el destino de la plataforma de su proyecto bajo prueba está configurado en x64.

Captura de pantalla de la configuración de la prueba

rubeonline
fuente
Esto me lo resolvió. En mi caso, tanto el proyecto que se está probando como el proyecto de prueba se establecieron en x86. Las pruebas fueron desagradables pero no se ejecutaron. Después de cambiarlo a Cualquier CPU, se ejecutaron las pruebas.
datchung
Simplemente tuve el mismo problema y esto lo resolvió. También sospecho bastante que esto puede haber tenido un efecto de negociación sinérgico malo en las referencias de mi proyecto principal, que de repente dejaron de cargar una DLL en particular, pero no han determinado de manera concluyente este efecto secundario desagradable.
Allen
44

Mi construcción tampoco encontró las pruebas. Mi configuración y solución para encontrar las pruebas son las siguientes.

Utilizo VSTS (Visual Studio Team Services) y tengo una compilación que está configurada para actualizar los paquetes NUGET en cada compilación. Estoy usando NUnit y descubrí que ejecutar el siguiente comando NUGET (desde la consola del administrador de paquetes en Visual Studio) para agregar la biblioteca NUnitTestAdapter a mi proyecto de prueba y la verificación de packages.config hizo que las pruebas se ejecutaran en mi compilación VSTS.

Install-Package NUnitTestAdapter

Como Maurice menciona en el comentario de esta publicación para NUnit3, use el siguiente paquete NUGET (busque otras utilidades en el enlace, es decir, dotnet CLI y Paket CLI)

Install-Package NUnit3TestAdapter

Espero que esto ayude.

Nick Rubino
fuente
10
También estoy usando VSTS actualmente. Como me aconsejaron, agregué NUnit3TestAdapter (ya que estoy usando NUnit 3.8.1) y esta solución resolvió mi problema. Gracias :-)
Maurice Klimek
1
Install-Package NUnit3TestAdapter resolvió mi problema :)
Bimal Das
26

En mi caso, tuve que:

1) convertir proj de prueba a netcore 2.0 (era netstandard 2.0)

2) agregue el paquete nuget xunit.runner.visualstudio

Referencia: http://www.neekgreen.com/2017/11/20/xunit-no-test-is-available/

woohoo
fuente
2
el mismo problema estaba conmigo. Estoy usando xunit con .net core
Amna
Esto también me funcionó en Visual Studio 2017 con xunit y .NET Core 2.1.
Thorkil Værge
3
en mi caso era un proyecto .net 4.6.1 así que lo único que faltaba era el corredor xunit. Lo instalé y funcionó.
Juan
1
Igual que Juan. Solo faltaba el paquete del corredor. Ejecutar esto en el administrador de paquetes para el proyecto de prueba lo resolvió: install-package xunit.runner.visualstudio
Premil
11

Recibí este error y pude resolverlo.

  1. Yo uso Visual Studio Professional 2017
  2. En VS, navegué a Herramientas -> Extensiones y actualizaciones
  3. En la parte superior del menú, noté que mi adaptador NUnit estaba desactivado
  4. Hice clic en el botón [Activar]
  5. Pude iniciar pruebas sin errores.
J Madera
fuente
¡Si! Y no olvide reiniciar Visual Studio. Eso era necesario para mí.
Michael Levy
"En la parte superior del menú", ¿qué significa eso?
Sean Kendle
1
@SaiyajinGohan. Después de completar el paso 2, aparece la ventana "Extensiones y actualizaciones". En la parte superior de esta ventana, vi que el adaptador NUnit estaba desactivado. Espero que esto aclare ...
J Wood
Gracias por eso, todavía no pude hacer que esto funcionara con el proyecto en el que estaba trabajando. Afortunadamente fue un proyecto de prueba y el siguiente funcionó. Sigue siendo un misterio el por qué.
Sean Kendle
10

Estoy usando MSTest. Para mí, la versión no coincide y falta otro paquete dependiente :

1) La carpeta de mi paquete contiene solo el paquete MSTest.TestFramework.1.2.1. En mi archivo de proyecto (.csproj), la referencia en el Nombre de destino era el paquete MSTest.TestAdapter.1.2.0 que no estaba presente en la carpeta del paquete. Mi packages.config también tiene una referencia de MSTest.TestFramework.1.2.0.

2) Así que instalé MSTest.TestAdapter.1.2.0 desde el administrador de paquetes nuget y alineé la versión MSTest.TestFramework a 1.2.0 en el proyecto y el archivo del paquete. Finalmente agrego Microsoft.VisualStudio.TestPlatform.TestFramework y Microsoft.VisualStudio.TestPlatform.TestFramework.Extensions en la referencia.

Entonces todo estuvo bien. Espero que esto ayude a alguien.

quásar
fuente
Me encontré con esto con .Net 4.6.1 VS2017. Terminé retrocediendo a 1.2.0; definitivamente, asegúrese de no tener dos versiones diferentes en la carpeta de paquetes o en el control de código fuente.
Jeremy Thompson
2
El mío pareció encontrar las pruebas, pero sí, el problema real era que faltaba "MSTest.TestAdapter". Sin errores agradables ni advertencias (VS2017 15.8). Todo se veía bien, excepto que no se encontraron pruebas, a pesar de aparecer en el explorador de pruebas ... Entonces, cuando hice "install-package MSTest.TestAdapter", de repente mis pruebas se ejecutaron como se esperaba. Gracias MS - 3 horas desperdiciadas ...........
James Joyce
1
La instalación de MSTest.TestAdapter 1.4.0 lo hizo por mí en VS 2019. Solo perdí 30 minutos gracias a ti.
furman87
6

Este problema vuelve a surgir para Visual Studio 2017. Probablemente otro error pero el mismo resultado.

Una solución alternativa que parece funcionar es desinstalar Microsoft Visual Studio 2017 Remote Debugger de la máquina afectada.

Csapi007
fuente
5
  1. Instale la última versión de Nunit y NUnitTestAdapter del paquete NUGET.
  2. Vaya a -> Prueba -> Configuración de prueba -> Arquitectura de procesador predeterminada -> Cambiar a X64
  3. Construye la solución.
  4. Esto resolverá el problema de Ejecutar prueba y depurador en la prueba unitaria y comenzará a funcionar.
Karthikeyan Nandagopalan
fuente
Esto realmente funcionó para mí después de golpearme la cabeza en tantas direcciones y sugerencias.
rajibdotnet
4

Me encontré con el mismo problema en VSTS con .Net 4.6.2. Si está viendo esto en la salida de su consola VSTS, la solución alternativa proporcionada por @Sushil todavía funciona en VSTS y es necesaria. Desafortunadamente, la tarea "Probar ensamblados" proporcionada por Microsoft pasa, por lo que realmente ni siquiera sabe que hay un problema a menos que verifique el resultado y no encuentre ninguna de sus pruebas realmente ejecutada.

Corrección de prueba VSTS

raterus
fuente
Mi problema fue con la Actualización 1 de TFS 2015 (local) y se solucionó con la Actualización 2. No estoy seguro de si el mismo problema existe / existía con VSTS.
Tore Østergaard
4

Si está ejecutando sus pruebas dentro de la ventana acoplable utilizando la compilación de varias etapas y no se encuentran las pruebas. Asegúrese de copiar todos los archivos, no solo los archivos del proyecto, como se muestra en la sección Dockerfile.

FROM mcr.microsoft.com/dotnet/core/sdk:2.2-stretch AS build
WORKDIR /src
COPY ["MainProject/FirstApp.csproj", "MainProject/"]
COPY ["TestProject/*", "TestProject/"]

RUN dotnet restore "TestProject/TestProject.csproj"
RUN dotnet build "TestProject/TestProject.csproj" -c Release
RUN dotnet test "TestProject/TestProject.csproj" -c Release
Bassam Gamal
fuente
Esto de hecho me mordió. Creo que la pista de que esto está sucediendo es que ENCUENTRA la DLL de prueba unitaria, pero NO encuentra ninguna prueba en ella. También descubrí que poner esto en línea después de sus declaraciones de copia le permitirá inspeccionar para ver qué se copió (aquí / app / tests es su directorio de destino en la imagen de Docker): RUN file = "$ (ls -al / app / tests) "&& echo $ file (consulte esta publicación para obtener más información sobre echo )
David Yates
3

Solucioné esto por problema en el proyecto de prueba VS 2017 y 4.6.2 con los siguientes pasos:

  1. Elimine las referencias a Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll y extensiones
  2. Instale el paquete nuget Microsoft.VisualStudio.QualityTools.UnitTestFramework.Updated
Ste Brown
fuente
3

Asegúrese de tener instalado el nuget "Microsoft.NET.Test.Sdk".

Lordpansar
fuente
2

Este es un problema conocido para .Net 4.6 ahora.

No se pueden ejecutar las pruebas unitarias de .Net 4.6.x como parte de una compilación de XAML TFS con TFS 2015 UPdate1 Fuente: https://connect.microsoft.com/VisualStudio/feedback/details/2245723

Aquí hay una pregunta similar para su referencia: No se pueden ejecutar las pruebas unitarias de .Net 4.6 del servidor de compilación XAML de TFS 2015

PatrickLu-MSFT
fuente
2
Hola Patrick. Los dos enlaces que proporcionas son casos abiertos por mí, por lo que no confiaría en ellos como referencia ;-).
Tore Østergaard
2

He arreglado este problema mediante la reinstalación de todas las pruebas relacionadas con los paquetes NuGet para el proyecto: Xunit, Xunit.runner.vistualstudio,Microsoft.Net.Test.Sdk

n.shojaei
fuente
1

Estaba teniendo un problema similar y noté que de alguna manera se app.confighabía agregado un archivo a mi proyecto de prueba. Al eliminar este archivo de configuración, me lo arregló.

thatWiseGuy
fuente
1

Arrojaré mi solución al montón. En mi caso, estoy agregando un par de proyectos a una solución existente junto con proyectos de prueba para ellos. Estamos usando MSTest. Había un archivo UnitTest.testsettings anterior habilitado en la solución que estaba causando problemas de compatibilidad.

Al hacer clic en el archivo de configuración, se eliminó la verificación y la ejecución de la prueba fue exitosa para mis pruebas.

ingrese la descripción de la imagen aquí

jwatts1980
fuente
1

¡Encontre una forma! Probablemente no sea el más ortodoxo, pero me ayudó a toda prisa:

  1. Actualice los paquetes MSTest.TestAdapter y MSTest.TestAdapterFramework a la versión 1.4.0 desde Herramientas> Administrador de paquetes NuGet.
  2. Luego limpie la solución y vuelva a ejecutar las pruebas.

No creo que sea nada particular con la versión, pero actualizarla ciertamente limpia cualquier referencia que sea mala en la solución / proyecto.

dave_077
fuente
0

Esto es solo para recapitular la solución presentada por @Sushil anteriormente.

Este es un problema conocido en Team Foundation Server 2015 RTM + Update 1 y se solucionará en la referencia de la Actualización 2 .

Hay una solución alternativa descrita por @Sushil aquí , que incluye agregar un archivo .runsettings que obliga al corredor de prueba a un marco .Net más antiguo (no tenga que especificarlo a través del cuadro de diálogo "Agregar / Editar ejecución de prueba" como agregarlo directamente en el editor de proceso de construcción se ignorará).

Tore Østergaard
fuente
0

Al usar .Net Core con una canalización de compilación en TFS 2017, mi paso de prueba de Visual Studio estaba pasando sin ejecutar ninguna prueba. Tuve que editar el paso, "Opciones de ejecución avanzadas" -> "Otras opciones de la consola" para incluir:

/framework:".NETCoreApp,Version=v2.0"

(Ese campo también contiene /platform:x64)

marca
fuente
0

En Visual Studio 2017, simplemente desinstalo y reinstalo NUnitTestAdapter o instalo un nuevo paquete como NUnitTestAdapter.WithFramework paquete y el problema desapareció.

Ali Yousefi
fuente
0

Recibí este error porque mi clase de prueba unitaria no era pública.

Ex:

class ClientTests

Error en la salida:

...\bin\Debug\Tests.dll] UTA001: TestClass attribute defined on non-public class ClientTests

Corrección:

public class ClientTests

Playa Jared
fuente
0

Tengo el mismo problema. Estoy usando Visual Studio 2017 Community Edition.

ingrese la descripción de la imagen aquí

Utilicé estos pasos para descubrir con éxito todos mis casos de prueba y ejecutarlos correctamente:

  • Primero vaya a Extensiones y actualizaciones, instale NUnit3 Test Adapter. Si ya lo ha hecho, habilítelo.

  • Reinicie su Visual Studio 2017, automáticamente le pedirá que
    instale su extensión, si un mensaje dice que finalice la tarea para continuar con la
    instalación, simplemente haga clic en "Finalizar tarea".

  • Después de eso, reconstruya su Proyecto de prueba y ahora se identificarán todos los casos de prueba y ahora puede comenzar a ejecutar sus casos de prueba.

Willy David Jr
fuente
0

En mi caso, reinstalar el adaptador Nunit3, eliminar carpetas temporales, cambiar la arquitectura y nada funcionó. Es debido a que Daemon Resharper causó el problema.

Add or Remove Programs> Find Resharper > Repair > Install again > Restart VS 

Eso resuelve los problemas.

Riyaz Hameed
fuente
0

Este error puede ocurrir para pruebas asíncronas si tiene el tipo de retorno incorrecto. El tipo de retorno debe ser Tarea y no anular.

usuario3533716
fuente
0

Después de agregar TestAdapterPath en el comandante, funcionó para mí:

vstest.console.exe Xom.Gci.Lvf.FileParserInvoker.UnitTests.dll /TestAdapterPath:"C:\****\****\{SolutionFolder}"
dixiashi
fuente
En primer lugar, debe asegurarse de que el caso de prueba se pueda ejecutar en VS IDE.
dixiashi
0

En mi caso, las pruebas se descubrieron, pero la ejecución dio como resultado "Prueba no disponible ... " y el (in) famoso: "Asegúrese de que el descubridor y ejecutores de la prueba estén registrados y que la configuración de la versión de plataforma y marco sea adecuada y vuelva a intentarlo".

el error fue independiente de Visual Studio (probado desde las herramientas de la CLI de dotnet y la prueba UNit casi desnuda) y fue solo cuando se apuntó a .NET 4.7.1. La aplicación dotnetcore funciona bien.

también la ejecución de pruebas con Nuint3 CLI nunit3-console.exe Tests.csprojmuestra el error:

"O bien el ensamblaje no contiene pruebas o no se ha encontrado el controlador de prueba adecuado".

el error se debió a que el adaptador de prueba no se pudo encontrar en una unidad de red (mapeada) o en un recurso compartido y se resolvió copiándolo localmente y volviéndolo a ejecutar.

Falco Alexander
fuente
0

Si ya instaló un adaptador de prueba en el proyecto de prueba, intente desinstalarlo del proyecto e instálelo nuevamente en el proyecto de prueba.

Esta solución básica funciona para mí.

Parth Darji
fuente
0

Pruebe a ejecutar vstest.console.execon --diag:diag.txte inspeccionar la salida. Para mí, fueron fallas de carga de DLL para adaptadores de prueba desde mi directorio de trabajo:

TpTrace Information: 0 : 14976, 1, 2020/03/10, 15:34:22.120, 57158093583, vstest.console.exe, AssemblyResolver.OnResolve: Microsoft.VisualStudio.TestPlatform.MSTest.TestAdapter: Failed to load assembly. Reason:System.IO.FileLoadException: Could not load file or assembly 'file:///C:\Directory\Microsoft.VisualStudio.TestPlatform.MSTest.TestAdapter.dll' or one of its dependencies. Operation is not supported. (Exception from HRESULT: 0x80131515)

File name: 'file:///C:\Directory\Microsoft.VisualStudio.TestPlatform.MSTest.TestAdapter.dll' ---> System.NotSupportedException: An attempt was made to load an assembly from a network location which would have caused the assembly to be sandboxed in previous versions of the .NET Framework. This release of the .NET Framework does not enable CAS policy by default, so this load may be dangerous. If this load is not intended to sandbox the assembly, please enable the loadFromRemoteSources switch. See http://go.microsoft.com/fwlink/?LinkId=155569 for more information.

Trabajé alrededor de esto agregando <loadFromRemoteSources enabled="true"/>debajo <runtime>en vstest.console.exe.config

andrew.rockwell
fuente
0

Yo uso MSTest.

Instalé desde Nuget la última versión de MSTest.TestFramework y reemplacé OOB Eliminar referencias a Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll

Luego instalado desde neget la última versión de Microsoft.TestPlatform

Me permitió ejecutar la prueba con un comando:

".\packages\Microsoft.TestPlatform.16.6.1\tools\net451\Common7\IDE\Extensions\TestPlatform\vstest.console.exe" "UnitTestProject1\bin\Debug\UnitTestProject1.dll" /logger:trx

Pero tengo el mismo error. La causa raíz del error es que no especifiqué un adaptador de prueba que analiza el ensamblaje y encuentra pruebas.

Solución:

  1. Instale un paquete nuget "MSTest.TestAdapter"

  2. Especifique un adaptador de prueba al final de un comando:

    /TestAdapterPath:".\packages\MSTest.TestAdapter.2.1.2\build_common "

MirrorBoy
fuente
0

Para aquellos que enfrentan un problema similar. Aquí está la solución, instale SpecFlowPlusRunner.

He intentado otras soluciones como reinstalar, eliminar el caché, etc. Pero la solución es realmente diferente, necesitamos instalar SpecRun.SpecFlow2.3.0 para visualstudio 2017. Esto ha resuelto el problema.

Espero que esto ayude a todos.

Laxmi
fuente
0

Enfrenté un problema similar cuando probé nUnit en VS 2017 y no es un proyecto principal. La instalación NUnit3TestAdaptersolucionó el problema.

Surendra Rayapati
fuente