Kein Test gefunden. Stellen Sie sicher, dass die installierten Einstellungen für Test Discovery & Executors, Plattform- und Framework-Version angemessen sind, und versuchen Sie es erneut

93

Ich bin dabei, unsere vorhandene Lösung auf .Net 4.6.1 zu aktualisieren, und konnte unsere Komponententests während eines Server-Builds nicht ausführen. Lokal werden sie wie erwartet ausgeführt, und wenn die Framework-Version auf .Net 4.5.1 zurückgesetzt wird, werden sie erneut auf dem Server ausgeführt.

Ich erhalte die folgende Fehlermeldung:

Kein Test gefunden. Stellen Sie sicher, dass die installierten Einstellungen für Test Discovery & Executors, Plattform und Framework-Version angemessen sind, und versuchen Sie es erneut.

Ich habe das Problem in einer einfacheren Einrichtung reproduziert:

  • Lösung mit einem einzelnen C # Unit Test-Projekt mit zwei Tests (einer fehlgeschlagen, einer bestanden).
  • XAML-Build-Definition unter Verwendung der Standardvorlage (TfvcTemplate.12.xaml)
  • TFS 2015 Update 1 XAML-Buildserver mit installiertem Visual Studio Enterprise 2015 Update 1 (haben sechs ähnliche Server und alle erzielen das gleiche Ergebnis)
Tore Østergaard
quelle
Laut Brian Harry von Microsoft ist dies ein Fehler, den sie derzeit untersuchen. Es sollte in Update 2 behoben werden und eine vorübergehende Problemumgehung sollte später veröffentlicht werden. Quelle: Link
Tore Østergaard
Ich habe das gleiche Problem für .Net 3.5 SP1 in Visual Studio 2013 Update 5.
Andrey Bushman
@AndreyBushman: Der Fehler könnte auch in 2013U5 auftreten, da er zusammen mit 2015RTM veröffentlicht wurde. Aber die Problemumgehung sollte auch in Ihrem Fall funktionieren.
Tore Østergaard
Ich hatte ein ähnliches Problem, die Problemumgehung war einfach in vs, unter den Testeinstellungen, um das richtige Standardprozessor-Bit (32/64) auszuwählen und die Engine nicht laufen zu lassen. (vs 2017.x)
kfn

Antworten:

58

Sie können versuchen, Ihre Standardprozessorarchitektur in Ihrer Testeinstellung von X86 auf X64 zu ändern . In meinem Fall war dies das Problem.

Dies geschieht, wenn das Plattformziel Ihres zu testenden Projekts auf festgelegt ist x64.

Screenshot der Testeinstellungen

rubeonline
quelle
Das hat es für mich gelöst. In meinem Fall wurden sowohl das zu testende Projekt als auch das Testprojekt auf x86 festgelegt. Tests waren nicht erkennbar, konnten jedoch nicht ausgeführt werden. Nachdem ich es in eine beliebige CPU geändert hatte, wurden Tests ausgeführt.
Datchung
Ich hatte gerade das gleiche Problem und das löste es. Ich bin auch ziemlich misstrauisch, dass dies einen schlechten negosynergistischen Effekt auf meine Hauptprojektreferenzen hatte, der plötzlich das Laden einer bestimmten DLL stoppte, aber diesen bösen Nebeneffekt nicht endgültig festgestellt hat.
Allen
44

Mein Build fand die Tests auch nicht. Mein Setup und meine Lösung zum Auffinden der Tests sind wie folgt.

Ich verwende VSTS (Visual Studio Team Services) und habe einen Build, der so konfiguriert ist, dass die NUGET-Pakete bei jedem Build aktualisiert werden. Ich verwende NUnit und habe festgestellt, dass das Ausführen des folgenden NUGET-Befehls (über die Paketmanagerkonsole in Visual Studio) zum Hinzufügen der NUnitTestAdapter-Bibliothek zu meinem Testprojekt und das Einchecken in der packages.config dazu führte, dass die Tests in meinem VSTS-Build ausgeführt wurden.

Install-Package NUnitTestAdapter

Wie Maurice im Kommentar zu diesem Beitrag für NUnit3 erwähnt, verwenden Sie das folgende NUGET-Paket (Suchen Sie unter dem Link nach anderen Dienstprogrammen, z. B.: Dotnet CLI und Paket CLI).

Install-Package NUnit3TestAdapter

Hoffe das hilft.

Nick Rubino
quelle
10
Ich benutze derzeit auch VSTS. Wie empfohlen, habe ich NUnit3TestAdapter hinzugefügt (da ich NUnit 3.8.1 verwende) und diese Lösung hat mein Problem gelöst. Vielen Dank :-)
Maurice Klimek
1
Install-Package NUnit3TestAdapter hat mein Problem gelöst :)
Bimal Das
25

In meinem Fall musste:

1) konvertiere test proj in netcore 2.0 (war netstandard 2.0)

2) Nuget-Paket hinzufügen xunit.runner.visualstudio

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

woohoo
quelle
2
Das gleiche Problem war bei mir. Ich benutze Xunit mit .net Core
Amna
Dies funktionierte auch für mich in Visual Studio 2017 mit xunit und .NET Core 2.1.
Thorkil Værge
3
In meinem Fall war ein .net 4.6.1-Projekt, daher fehlte nur der xunit-Läufer. Installiert und funktioniert.
Juan
1
Gleich wie Juan. Nur das Runner-Paket fehlte. Das Ausführen im Paketmanager für das Testprojekt hat das Problem behoben: install-package xunit.runner.visualstudio
Premil
11

Ich habe diesen Fehler erhalten und konnte ihn beheben.

  1. Ich benutze Visual Studio Professional 2017
  2. In VS navigierte ich zu Extras -> Erweiterungen und Updates
  3. Oben im Menü war mir aufgefallen, dass mein NUnit-Adapter deaktiviert war
  4. Ich habe auf die Schaltfläche [Aktivieren] geklickt
  5. Ich konnte fehlerfreie Tests starten.
J Wood
quelle
Ja! Vergessen Sie nicht, Visual Studio neu zu starten. Das war für mich erforderlich.
Michael Levy
"Oben im Menü" Was bedeutet das?
Sean Kendle
1
@ SaiyajinGohan. Nachdem Sie Schritt 2 abgeschlossen haben, wird das Fenster "Erweiterungen und Updates" angezeigt. Oben in diesem Fenster sah ich, dass der NUnit-Adapter deaktiviert war. Hoffe das klärt sich ....
J Wood
Vielen Dank dafür, ich konnte das mit dem Projekt, an dem ich arbeitete, immer noch nicht zum Laufen bringen. Zum Glück war es ein Testprojekt und das nächste hat funktioniert. Immer noch ein Rätsel, warum.
Sean Kendle
10

Ich benutze MSTest. Für mich war es Version Missmatch und es fehlte ein anderes abhängiges Paket -

1) Mein Paketordner enthält nur das Paket MSTest.TestFramework.1.2.1. In meiner Projektdatei (.csproj) war die Referenz im Zielnamen das Paket MSTest.TestAdapter.1.2.0, das nicht im Paketordner vorhanden war. Meine packages.config enthält auch einen Verweis auf MSTest.TestFramework.1.2.0.

2) Also habe ich MSTest.TestAdapter.1.2.0 vom Nuget-Paketmanager installiert und die MSTest.TestFramework-Version in Projekt- und Paketdatei auf 1.2.0 ausgerichtet. Schließlich füge ich Microsoft.VisualStudio.TestPlatform.TestFramework und Microsoft.VisualStudio.TestPlatform.TestFramework.Extensions in die Referenz ein.

Dann war alles in Ordnung. Hoffe das hilft jemandem.

Quasar
quelle
Ich bin mit .Net 4.6.1 VS2017 darauf gestoßen. Am Ende habe ich ein Rollback auf 1.2.0 durchgeführt - stellen Sie auf jeden Fall sicher, dass Sie nicht zwei verschiedene Versionen in Ihrem Paketordner oder in der Quellcodeverwaltung haben.
Jeremy Thompson
2
Meins schien die Tests zu finden, aber ja, das Fehlen von "MSTest.TestAdapter" war das eigentliche Problem. Keine netten Fehler oder Warnungen (VS2017 15.8). Alle sahen gut aus, außer dass keine Tests gefunden wurden, obwohl sie im Test-Explorer angezeigt wurden. Als ich also das "Installationspaket MSTest.TestAdapter" ausführte, liefen meine Tests plötzlich wie erwartet. Danke MS - 3 Stunden verschwendet ...........
James Joyce
1
Die Installation von MSTest.TestAdapter 1.4.0 hat dies für mich in VS 2019 erledigt. Ich habe dank Ihnen nur 30 Minuten verschwendet.
Furman87
6

Dieses Problem tritt erneut für Visual Studio 2017 auf. Höchstwahrscheinlich ein weiterer Fehler, aber das gleiche Ergebnis.

Eine Problemumgehung, die zu funktionieren scheint, besteht darin, Microsoft Visual Studio 2017 Remote Debugger von dem betroffenen Computer zu deinstallieren.

Csapi007
quelle
4

Ich bin in VSTS mit .Net 4.6.2 auf dasselbe Problem gestoßen. Wenn Sie dies in Ihrer VSTS-Konsolenausgabe sehen, funktioniert die von @Sushil bereitgestellte Problemumgehung weiterhin in VSTS und wird benötigt. Leider besteht die von Microsoft bereitgestellte Aufgabe "Test Assemblies", sodass Sie nicht einmal wissen, dass ein Problem vorliegt, es sei denn, Sie überprüfen die Ausgabe und stellen fest, dass keiner Ihrer Tests tatsächlich ausgeführt wurde!

VSTS Test Fix

raterus
quelle
Mein Problem war mit (On-Prem) TFS 2015 Update 1 und es wurde mit Update 2 behoben. Ich bin nicht sicher, ob das gleiche Problem mit VSTS existiert / existierte.
Tore Østergaard
4

Wenn Sie Ihre Tests in Docker mit mehrstufiger Erstellung ausführen und keine Tests gefunden werden. Stellen Sie sicher, dass Sie alle Dateien kopieren, nicht nur Projektdateien wie im Abschnitt 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
quelle
Das hat mich wirklich gebissen. Ich denke, der Hinweis darauf, dass dies geschieht, ist, dass es die Unit-Test-DLL FINDET, aber es findet KEINE Tests darin. Ich habe auch festgestellt, dass Sie durch Inline-Einfügen nach Ihren Kopieranweisungen überprüfen können, was kopiert wurde (hier ist / app / tests Ihr Zielverzeichnis im Docker-Image): RUN file = "$ (ls -al / app / tests) "&& echo $ file (siehe diesen Beitrag für weitere Informationen über echo )
David Yates
4
  1. Installieren Sie die neueste Version von Nunit und NUnitTestAdapter aus dem NUGET-Paket.
  2. Gehen Sie zu -> Test -> Testeinstellungen -> Standardprozessorarchitektur -> Wechseln Sie zu X64
  3. Erstellen Sie die Lösung.
  4. Dadurch wird das Problem "Test und Debugger ausführen" beim Komponententest behoben und es funktioniert.
Karthikeyan Nandagopalan
quelle
3

Ich habe dieses Problem im VS 2017 & 4.6.2-Testprojekt mit den folgenden Schritten behoben:

  1. Entfernen Sie Verweise auf Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll und Erweiterungen
  2. Installieren Sie das Microsoft.VisualStudio.QualityTools.UnitTestFramework.Updated-Nuget-Paket
Ste Brown
quelle
3

Stellen Sie sicher, dass das Nuget "Microsoft.NET.Test.Sdk" installiert ist.

Lordpansar
quelle
2

Dies ist jetzt ein bekanntes Problem für .Net 4.6.

.Net 4.6.x-Komponententests können nicht als Teil eines XAML-TFS-Builds mit TFS 2015 UPdate1 ausgeführt werden. Quelle: https://connect.microsoft.com/VisualStudio/feedback/details/2245723

Hier ist eine ähnliche Frage für Ihre Referenz: .Net 4.6-Komponententests des TFS 2015 XAML-Buildservers können nicht ausgeführt werden

PatrickLu-MSFT
quelle
2
Hallo Patrick. Beide von Ihnen angegebenen Links sind von mir geöffnete Fälle, daher würde ich ihnen nicht als Referenz vertrauen ;-).
Tore Østergaard
2

Ich reparierte dieses Problem , indem alle Tests Neuinstallation NuGet Pakete für das Projekt bezogen werden : Xunit, Xunit.runner.vistualstudio,Microsoft.Net.Test.Sdk

n.shojaei
quelle
1

Ich bekam ein ähnliches Problem und bemerkte app.config, dass meinem Testprojekt irgendwie eine Datei hinzugefügt wurde. Durch das Entfernen dieser Konfigurationsdatei wurde das Problem für mich behoben.

thatWiseGuy
quelle
1

Ich werde meine Lösung auf den Haufen werfen. In meinem Fall füge ich einer vorhandenen Lösung einige Projekte sowie Testprojekte für diese hinzu. Wir verwenden MSTest. Für die Lösung war zuvor eine UnitTest.testsettings-Datei aktiviert, die Kompatibilitätsprobleme verursachte.

Durch Klicken auf die Einstellungsdatei wurde die Prüfung entfernt und der Testlauf für meine Tests war erfolgreich.

Geben Sie hier die Bildbeschreibung ein

jwatts1980
quelle
1

Einen Weg gefunden! Wahrscheinlich nicht das orthodoxste, aber es hat mir in Eile geholfen:

  1. Aktualisieren Sie die Pakete MSTest.TestAdapter und MSTest.TestAdapterFramework über Tools> NuGet Package Manager auf 1.4.0.
  2. Reinigen Sie die Lösung und führen Sie die Tests erneut durch.

Ich denke nicht, dass die Version etwas Besonderes ist, aber das Aktualisieren bereinigt auf jeden Fall alle Referenzen, die in der Lösung / im Projekt schlecht sind.

dave_077
quelle
0

Dies ist nur eine Zusammenfassung der zuvor von @Sushil vorgebrachten Lösung.

Dies ist ein bekanntes Problem in Team Foundation Server 2015 RTM + Update 1 und wird in Update 2, Referenz , behoben .

Es gibt eine von @Sushil hier beschriebene Problemumgehung , die das Hinzufügen einer .runsettings-Datei umfasst, die den Testläufer zu einem älteren .Net-Framework zwingt (bitte nicht, dass Sie ihn über das Dialogfeld "Testlauf hinzufügen / bearbeiten" angeben müssen, um ihn direkt hinzuzufügen im Build-Prozess-Editor wird ignoriert).

Tore Østergaard
quelle
0

Bei Verwendung von .Net Core mit einer Build-Pipeline in TFS 2017 wurde mein Visual Studio-Testschritt bestanden, ohne dass tatsächlich Tests ausgeführt wurden. Musste den Schritt "Erweiterte Ausführungsoptionen" -> "Andere Konsolenoptionen" bearbeiten, um Folgendes einzuschließen:

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

(Dieses Feld enthält auch /platform:x64)

Kennzeichen
quelle
0

In Visual Studio 2017 deinstalliere und installiere ich einfach NUnitTestAdapter oder installiere ein neues Paket wie NUnitTestAdapter.WithFramework-Paket und Problem verschwunden.

Ali Yousefi
quelle
0

Ich habe diesen Fehler erhalten, weil meine Unit-Testklasse nicht öffentlich war.

Ex:

class ClientTests

Fehler bei der Ausgabe:

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

Korrektur:

public class ClientTests

Jared Beach
quelle
0

Ich habe das gleiche Problem. Ich verwende Visual Studio 2017 Community Edition.

Geben Sie hier die Bildbeschreibung ein

Ich habe diese Schritte verwendet, um alle meine Testfälle erfolgreich zu erkennen und erfolgreich auszuführen:

  • Gehen Sie zuerst zu Erweiterungen und Updates und installieren Sie den NUnit3-Testadapter. Wenn Sie bereits haben, aktivieren Sie es einfach.

  • Starten Sie Visual Studio 2017 neu. Es wird automatisch aufgefordert,
    Ihre Erweiterung zu installieren. Wenn Sie aufgefordert werden, die Aufgabe zu beenden, um die
    Installation fortzusetzen , klicken Sie einfach auf " Aufgabe beenden ".

  • Erstellen Sie anschließend Ihr Testprojekt neu, und alle Testfälle werden identifiziert. Sie können nun mit der Ausführung Ihrer Testfälle beginnen.

Willy David Jr.
quelle
0

In meinem Fall hat die Neuinstallation des Nunit3-Adapters, das Löschen von temporären Ordnern, das Ändern der Architektur und nichts funktioniert. Es liegt am Daemon Resharper, der das Problem verursacht hat.

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

Das löst die Probleme.

Riyaz Hameed
quelle
0

Dieser Fehler kann bei asynchronen Tests auftreten, wenn Sie den falschen Rückgabetyp haben. Der Rückgabetyp sollte Task und nicht ungültig sein.

user3533716
quelle
0

Nachdem ich den TestAdapterPath im Commander hinzugefügt habe, hat es für mich funktioniert:

vstest.console.exe Xom.Gci.Lvf.FileParserInvoker.UnitTests.dll /TestAdapterPath:"C:\****\****\{SolutionFolder}"
Dixiashi
quelle
Zunächst sollten Sie sicherstellen, dass der Testfall in der VS-IDE ausgeführt werden kann.
Dixiashi
0

In meinem Fall wurden die Tests entdeckt, aber das Ausführen führte zu "Test nicht verfügbar ... " und dem (in) berühmten: "Stellen Sie sicher, dass Test Discovery und Executor registriert sind und die Einstellungen für die Plattform- und Framework-Version angemessen sind, und versuchen Sie es erneut."

Der Fehler war unabhängig von Visual Studio (getestet mit Dotnet CLI-Tools und nahezu nacktem UNit-Test) und nur beim Targeting von .NET 4.7.1. Die Dotnetcore-App funktioniert einwandfrei.

Auch das Ausführen von Tests mit der Nuint3-CLI nunit3-console.exe Tests.csprojzeigt den Fehler:

"Entweder enthält die Baugruppe keine Tests oder es wurde kein geeigneter Testtreiber gefunden."

Der Fehler lag darin, dass der Testadapter nicht auf einem (zugeordneten) Netzwerklaufwerk oder einer freigegebenen Freigabe gefunden wurde und durch lokales Kopieren und erneutes Ausführen behoben wurde .

Falco Alexander
quelle
0

Wenn Sie bereits einen Testadapter im Testprojekt installiert haben, versuchen Sie, das Projekt zu deinstallieren und erneut im Testprojekt zu installieren.

Diese grundlegende Lösung funktioniert für mich.

Parth Darji
quelle
0

Versuchen Sie es vstest.console.exemit --diag:diag.txtund überprüfen Sie die Ausgabe. Für mich waren es DLL-Ladefehler für Testadapter aus meinem Arbeitsverzeichnis:

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.

Ich habe dies umgangen, indem ich in vstest.console.exe.config <loadFromRemoteSources enabled="true"/>unter <runtime>hinzugefügt habe

andrew.rockwell
quelle
0

Ich benutze MSTest.

Ich habe von Nuget die neueste Version von MSTest.TestFramework installiert und OOB ersetzt. Verweise auf Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll entfernen

Dann von neget die neueste Version von Microsoft.TestPlatform installiert

Es erlaubte mir, den Test mit einem Befehl auszuführen:

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

Aber ich habe den gleichen Fehler bekommen. Die Hauptursache für den Fehler, dass ich keinen Testadapter angegeben habe, der die Assembly analysiert und Tests findet.

Lösung:

  1. Installieren Sie ein Nuget-Paket "MSTest.TestAdapter"

  2. Geben Sie am Ende eines Befehls einen Testadapter an:

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

MirrorBoy
quelle
0

Für diejenigen, die mit einem ähnlichen Problem konfrontiert sind. Hier ist die Lösung: Bitte installieren Sie SpecFlowPlusRunner.

Ich habe vielleicht andere Lösungen wie Neuinstallation, Löschen des Caches usw. ausprobiert. Aber die Lösung ist tatsächlich anders. Wir müssen SpecRun.SpecFlow2.3.0 für Visualstudio 2017 installieren. Dies hat das Problem gelöst.

Hoffe das hilft allen.

Laxmi
quelle
0

Ich hatte ein ähnliches Problem, als ich nUnit in VS 2017 ausprobierte, und es ist kein Kernprojekt. Die Installation hat NUnit3TestAdapterdas Problem behoben.

Surendra Rayapati
quelle