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 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)

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.

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.

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/

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.

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.

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.

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!

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

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.

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

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

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

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

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.

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.

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.

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

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)

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

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

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

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.

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.

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

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}"

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 .

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.

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

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 "

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.

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