Ich habe Probleme mit VS 2017, seit ich es installiert habe. Jetzt scheinen Unit-Tests nur über die Befehlszeile "Dotnet-Test" ausgeführt zu werden.

Mein Projekt ist .NET Core 1.1.1. Ich habe das SDK und das Framework-Update für 1.1.1 installiert.

Ich habe das Beispiel bei MSDN ( https://msdn.microsoft.com/en-us/library/ms182532.aspx ) ausprobiert, das ebenfalls genauso fehlschlägt.

Alle NuGet-Pakete für die Tests und das Hauptprojekt sind aktuell. Und sowohl das Testprojekt als auch das Hauptprojekt werden fehlerfrei erstellt. Die Tests werden erfolgreich über die Befehlszeile ausgeführt.

Hat jemand Unit Tests für VS 2017 erhalten, wenn ja, wie?

Danke, John

Update - Erweitern

Hier ist ein Beispiel für ein einfaches Testprojekt, das auf GitHub nicht funktioniert . Dies ist ein Beispiel mit xUnit, aber ich habe NUnit und Visual Studio in MS-Tests ausprobiert. Unabhängig davon, welche Tests oder Änderungen ich vornehme, kann ich den VS-Testläufer nicht dazu bringen, Tests zu finden.

Was ich versucht habe

• Löschen von VS-Test-Cache-Dateien DEL %TEMP%\VisualStudioTestExplorerExtensions
• VS neu starten
• Test Explorer schließen / öffnen
• für xUnit installiert Microsoft.DotNet.InternalAbstractions( siehe SO-Beitrag )
• Stellen Sie für NUnit sicher, dass der Adapter installiert ist und dieselbe Version (3) wie das NUnit-Paket aufweist
• test -> test settings -> default processor architecture ist auf x86 eingestellt

Die Frage
Kann jemand bitte ein funktionierendes Beispiel für eine .Net Core 1.1.0-Lösung in VS2017 (.csproj-Projektdateien) bereitstellen, bei der der VS-Test-Explorer die Komponententests erfolgreich findet, ODER mir das Problem im angegebenen Beispiel zeigen.

In meinem Fall stellte sich heraus, dass ich einfach meine Testadapter und mein Testframework aktualisieren musste . Getan.

Beispiel mit dem NuGet Package Manager:

Dies hat nur bei mir funktioniert (ich weiß nicht, ob es das Ergebnis einer Änderung der Arbeitsbereiche ist, die etwas beschädigt hat):

Löschen von VS-Testcache-Dateien in% TEMP% \ VisualStudioTestExplorerExtensions und Starten von VS2017.

Die API für Testadapter für .NET Core wurde mit der Veröffentlichung von Visual Studio 2017 und dem Wechsel vom project.jsonFormat zum csprojFormat geändert . Dies machte die vorhandenen dotnet-test-*Adapter wie dotnet-test-nunitveraltet.

Die Adapter wurden aktualisiert, aber die Art und Weise, wie Sie Tests in Visual Studio oder in der Befehlszeile einrichten und ausführen, dotnet testerfordert unterschiedliche Referenzen in Ihren Testprojekten. Achten Sie auf jegliche Dokumentation, die Referenzpakete im dotnet-test-*Format finden, da sie veraltet sind.

Zunächst muss Ihr Testprojekt auf eine bestimmte Plattform abzielen, entweder .NET Core oder .NET Framework. Es kann nicht auf .NET Standard abzielen, selbst wenn der zu testende Code .NET Standard ist. Dies liegt daran, dass das Ziel der Tests angibt, auf welcher Plattform die Tests ausgeführt werden sollen. .NET Standard ist insofern wie eine PCL (Portable Class Library), als es auf vielen Plattformen ausgeführt werden kann.

Als Nächstes müssen Sie Verweise auf Microsoft.NET.Test.Sdkdas Testframework Ihrer Wahl und einen kompatiblen Testadapter hinzufügen . Für NUnit sehen Ihre Referenzen folgendermaßen aus:

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

Ein Kommentar oben erwähnt das Hinzufügen von,

<ItemGroup>
    <Service Include="{82a7f48d-3b50-4b1e-b82e-3ada8210c358}" />
</ItemGroup>

Dies ist nicht unbedingt erforderlich, kann aber helfen. Es wird von Visual Studio automatisch zu allen Unit-Test-Projekten hinzugefügt, damit Projekte mit Tests schnell gefunden werden können.

Wenn Ihre Tests nicht in Visual Studio angezeigt werden, müssen Sie zunächst versuchen, Ihre Lösung zu schließen und sie dann erneut zu öffnen. In Visual Studio scheint es Fehler zu geben, die Änderungen an Projekten beim Bearbeiten nicht erkennen.

Weitere Informationen finden Sie unter Testen von .NET Core mit NUnit in Visual Studio 2017

Ich hatte das gleiche Problem und brachte es zum Laufen, indem ich Folgendes tat ..:

• Schließen Sie zuerst alle geöffneten Visual Studio-Instanzen und löschen Sie diesen Ordner:% TEMP% \ VisualStudioTestExplorerExtensions. ( Ausführen von Tests mit Visual Studio )
• Gehen Sie zu Ihrem Nuget-Paketmanager und installieren Sie zuerst Microsoft.NET.Test.Sdk (15.3.0-Vorschau-20170425-07) und dann xunit.runner.visualstudio (2.3.0-beta1-build1309). Im beigefügten Nuget-Screenshot sehen Sie alle Pakete, die ich installieren musste, um das neueste VS 2017 zum Erkennen meiner Tests zu erhalten.

Das Vergessen, die Testklasse öffentlich zu machen, verhindert, dass die darin enthaltenen Testmethoden entdeckt werden

Ich hatte ein Standard-xUnit-Projekt und löschte das Beispiel UnitTest1.cs und ersetzte es durch eine Controller-Testklasse mit einigen Tests, aber es wurden keine gefunden

Kurz gesagt, nachdem ich die Pakete xUnit, Test.Sdk, xUnit.runner aktualisiert und das Projekt neu erstellt habe, ist ein Erstellungsfehler aufgetreten:

Fehler xUnit1000 Testklassen müssen öffentlich sein

Zum Glück hat die aktualisierte Version diese Ausnahme ausgelöst, um mir einige Probleme zu ersparen

Das Ändern der Testklasse, um öffentlich zu sein, hat mein Problem behoben

In meinem Fall habe ich das Testprojekt auf x64Architektur ausgerichtet und die geänderte Testeinstellung Architektur (Test-> Standardprozessorarchitektur) wurde auf gesetzt x86. Sie passten nicht zusammen.

Nach dem Zurücksetzen der Testeinstellung Architektur auf x64und dem erneuten Erstellen wurden alle Tests erneut erkannt.

Ich hatte Probleme mit VS 2017, meinen UnitTest zu finden. Es war nicht das genaue Problem, das John stellte - aber dies war das erste Ergebnis in Google, nach dem ich gesucht habe, also wollte ich mein Problem teilen.

Ich hatte eine Legacy-Lösung von VS2010 über VS2013, VS2015. In VS2017 scheinen sich die Namespaces für das [TestMethod]Attribut geändert zu haben.

Bevor es benutzt wurde

Microsoft.VisualStudio.QualityTools.UnitTestFramework, Version=10.0.0.0

Ich habe eine neue Test.dll im Projekt erstellt und diese standardmäßig verwendet

Microsoft.VisualStudio.TestPlatform.TestFramework, Version=14.0.0.0

Meine Lösung bestand also darin, ein neues UnitTest-Projekt in VS2017 zu erstellen. Vielleicht hätte das Ändern der Baugruppenreferenzen für das alte Testprojekt auch funktioniert. Mit der neuen Referenz entdeckte VS2017 diese Unit-Tests.

Lesen Sie keine veralteten Artikel unter MSDN. .NET Core-relevante Materialien finden Sie unter docs.microsoft.com

https://docs.microsoft.com/en-us/dotnet/articles/core/testing/

Im Allgemeinen benötigen Sie eine .NET Core-Konsolen-App, um die Unit-Testfälle zu enthalten.

Für mich war das Problem, dass ich versehentlich Testfälle in eine interne Klasse eingeordnet habe

[TestClass]
  internal class TestLib {
}

Dies führte dazu, dass Testfälle nicht identifiziert wurden.

Stellen Sie sicher, dass Sie das richtige Microsoft.NET.Test.Sdk verwenden:

<PackageReference Include="Microsoft.NET.Test.Sdk" Version="15.0.0" />

Verwenden Sie keine Vorabversion. Oder Sie müssen zur Konsolen-App (nicht zur Bibliothek) wechseln. Ich habe ein ähnliches Problem, aber mit der neuesten Version (15.0.0) funktioniert es wieder.

Außerdem müssen Sie möglicherweise Folgendes hinzufügen:

  <ItemGroup>
    <Service Include="{82a7f48d-3b50-4b1e-b82e-3ada8210c358}" />
  </ItemGroup>

aber ich denke nicht, dass es notwendig ist.

Ich weiß, dass OP dies auf seiner Checkliste aufgeführt hat, aber es ist leicht, diesen Punkt zu übersehen, wenn Sie Visual Studio 2017 neu installieren und ein neues Projekt einrichten. Abgesehen von der NUnit-Projektvorlage und dem NUnit Framework muss der NUnit-Adapter separat installiert werden, z Install-Package NUnit3TestAdapter -Version 3.9.0. B. mit dem Befehl NuGet . Danach begann Visual Studio Community 2017, Unit-Tests ohne Probleme zu entdecken.

In meinem Fall konnte der Test Explorer meine Tests nicht finden, nachdem ich das Projekt auf eine neue Lösung verschoben hatte.

Die Antwort war einfach, dass ich in meinem Projekt einen Verweis auf den alten MS-Testadapter hatte.

Ich hatte ein Duplikat der folgenden Zeile für Version 1.1.11 des MS-Testadapters in meiner cs.proj-Datei:

<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')" />

Um das Problem zu lösen,

1. Klicken Sie mit der rechten Maustaste auf Projekt und wählen Sie "Projekt entladen".
2. Klicken Sie mit der rechten Maustaste auf Projekt und wählen Sie "Bearbeiten".
3. Entfernen Sie die Zeile, die die alte Version des Adapters importiert.
4. Klicken Sie mit der rechten Maustaste auf das Projekt und wählen Sie "Projekt neu laden".
5. Lösung / Projekt neu erstellen

Hatte gerade dieses Problem damit, dass Visual Studio meine Tests nicht finden konnte, die Schaltfläche zum Ausführen neben der Methode nicht sehen konnte und sie nicht durch Ausführen aller Tests im Projekt erkannt wurden.

Es stellte sich heraus, dass meine Testklasse nicht öffentlich war! Durch die Veröffentlichung konnte VS die Tests ermitteln.

Für mich war es einfacher, ein neues Testprojekt zu erstellen, das mit Visual Studio 2017 einwandfrei funktioniert ... und einfach die Testdateien zu kopieren, Referenzen hinzuzufügen und NuGet-Pakete nach Bedarf.

In meinem Fall war es ein Projekt, bei dem ich das Testprojekt von einer früheren .NET-Version aktualisiert hatte. In der app.config hatte ich Assemblybindungen zu früheren Versionen der abhängigen Assemblys.

Nachdem ich die Assembnlybindings in der app.config behoben hatte, wurden meine Tests entdeckt.

Entdeckung

Die oben genannten Top-Antworten haben bei mir nicht funktioniert (Neustart, Aktualisierung auf Version 1.1.18 ... Ich wurde bereits aktualisiert, Löschen der temporären Dateien, Löschen des NuGet-Cache usw.).

Was ich entdeckte, war, dass ich in verschiedenen Testprojekten unterschiedliche Verweise auf MSTest.TestAdapter und MSTest.Framework hatte (meine Lösung hat zwei). Einer wurde auf 1.1.18 hingewiesen wie ...

packages.config

<package id="MSTest.TestAdapter" version="1.1.18" targetFramework="net461" />
<package id="MSTest.TestFramework" version="1.1.18" targetFramework="net461" />

... aber ein anderer hat die Verweise auf 1.1.11. Einige der obigen Antworten führen zu dieser Entdeckung, als zwei Versionen der Bibliotheken nach dem Neustart von Visual Studio in meinem temporären Verzeichnis (% TEMP% \ VisualStudioTestExplorerExtensions \) angezeigt wurden.

Lösung

Durch einfaches Aktualisieren meiner packages.config auf die Version 1.1.18 wurde die Funktionalität meiner Unit-Tests in VS wiederhergestellt. Es scheint, dass es einige Fehler gibt, die keine direkten Verweise auf die MSTest-Bibliotheken zulassen. Hoffe das hilft dir.

Mehr Info:

• Visual Studio 2017 Ent: 15.5.6 (Ich hatte von 15.0.1 aktualisiert, um dieses Problem zu beheben, aber ich hatte es in beiden)

Die Lösung bestand darin, meine app.configDatei aus meinem Unit-Test-Projekt zu entfernen . Die Tests werden erneut angezeigt!

Diese Datei verwies auf einige DLLs in den Bindingredirects, die in den Projektreferenzen nicht vorhanden waren. Fügen Sie die für Ihr Projekt unbedingt erforderlichen Baugruppenbindungen erneut hinzu.

In meinem Fall war das UWP-Projekt in der Lösung vorhanden, die das Problem verursachte.

Beim Entladen des UWP-Projekts wurden Tests entdeckt. Wenn ich es zurück geladen habe, ist der Test wieder verschwunden.

Versuchen Sie, alle Projekte zu entladen und nur das Testprojekt beizubehalten. In Test Runner werden zehn Wiederherstellungslösungen und Test-Shounds angezeigt. Laden Sie die Projekte nacheinander und erstellen Sie die Lösung jedes Mal neu, um herauszufinden, welches Projekt das Problem verursacht

Beispiel Repo

VS-Fehlerbericht

Das Thema

Das Problem ist, dass Visual Studio über die Dotnet-Core-Versionen auf dem Computer "verwirrt" wird. Als ich zur Systemsteuerung ging -> Programme deinstallieren, hatte ich 8 verschiedene Dotnet Core SDKs und Runtimes installiert. Dies führte dazu, dass VS beim Versuch, Tests zu finden, stillschweigend einen Fehler aufwies.

Überprüfen Sie das Problem

Sie können das Problem überprüfen, indem Sie in der Befehlszeile die Version von dotnet abrufen, auf der Sie sich befinden $ dotnet --version. Wenn Sie außer der neuesten Version, die Sie installiert haben, etwas sehen, stimmt Ihr Computer nicht überein und verwendet nicht die richtige Version. Beispiel ... Wenn Sie Dotnet Core 1.0.1installiert haben, aber die Version an der Eingabeaufforderung erhalten und es heißt, dass 1.0.0dies ein Problem ist.

Die Lösung

Löschen Sie alle alten Sachen. Ich habe nur mit dem begonnen, was ich entfernen musste (die ältesten Dotnet-RC-Versionen), aber beim Testen des Problems wurde immer noch die falsche Version angezeigt. Schließlich räumte ich ein, eine vollständige Reinigung durchzuführen. ICH...

• Deinstallierte alle Visual Studio-Anwendungen (auf meinem Computer VS2015 und VS2017).
• Deinstallierte alle Versionen von Dotnet Core (auch die neuesten)

Nachdem mein Computer vollständig leer war, habe ich nur VS2017 installiert (es wird mit dem neuesten Dotnet geliefert). Ich habe ein xUnit-Testprojekt erstellt und der Test-Explorer hat den Test sofort gelöst gefunden

Das mag übertrieben erscheinen, aber ich habe zwei Wochen lang versucht, dies auf andere Weise zu beheben. Wenn Sie das Problem haben, tun Sie es einfach, obwohl es Stunden dauern kann, Elemente zu deinstallieren / neu zu installieren, wird es Ihnen wahrscheinlich Zeit sparen.

Verweise

• Weitere Informationen zur Behebung des Problems finden Sie im Blog-Beitrag @epestic .

Ich habe alles versucht, aber nichts hat geholfen. In meinem Fall hatte ich eine Lösung mit mehreren Testprojekten und einige von ihnen verwendeten das alte MS-Test-Framework, sodass Visual Studio nur diese fand.

Ich habe die Test-Framework-Pakete für alle Testprojekte installiert, wie in der akzeptierten Antwort gezeigt . Dann wurden die Verweise auf die alten Qualitätstools entfernt, Visual Studio neu gestartet und jetzt kann ich alle Tests sehen.

Für C ++:

Da es für C ++ - Tests keine spezielle Frage gibt, das Thema jedoch sehr ähnlich ist, hat mir Folgendes geholfen, als ich Probleme mit der Testerkennung hatte.

Wenn Sie die Desktop-Entwicklung nur mit C ++ installiert haben , besteht die Lösung darin, die Universal Windows Platform-Entwicklung auch mit den optionalen C ++ Universal Windows Platform-Tools zu installieren . Sie können diese im Visual Studio-Webinstallationsprogramm auswählen.

Erstellen Sie anschließend Ihr Testprojekt neu, und die Testerkennung sollte funktionieren.

Übrigens habe ich das Unit-Test-Projekt in VS2017 erstellt. Es könnte wichtig sein, da einige Benutzer erwähnt haben, dass sie Erkennungsprobleme in Projekten hatten, die von VS2015 auf VS2017 migriert wurden.

Das Entfernen der alten DLL sollte helfen. Löschen von temporären Dateien im Verzeichnis% TEMP% unter C: \ Benutzer (Ihr Benutzername) \ AppData \ Local \ Temp

Ich hatte das gleiche Problem. Meine Lösung war in Ordnung, aber als ich die Lösung öffnete, stellte ich plötzlich fest, dass die Tests weg sind.

Schließlich habe ich ein Downgrade durchgeführt Microsoft.VisualStudio.TestPlatform.TestFrameworkund Microsoft.VisualStudio.TestPlatform.TestFramework.ExtensionsPakete auf eine sehr alte Version (mit NuGet Manager) und Testmethoden angezeigt. Dann habe ich auf die neueste Version aktualisiert und es waren immer noch da.

Also einfach Downgrade und Upgrade-Pakete.

In meinem Fall hilft mir keine der oben genannten. Aber ich stufe NUNit3TestAdapter auf Version 3.8.0 herunter und aktualisiere dann auf die neueste Version (3.10.0).

Manchmal funktioniert es, den Namespace der Tests zu ändern. Ich hatte die Ordnerstruktur wie folgt:

A |___B | |___D |___C___E

Der Namespace war flach wie Tests. <Name> und sie wurden nicht im Testfenster angezeigt. Als ich den Namespace in die Struktur des Verzeichnisses änderte, wurden alle Tests angezeigt. Jetzt konnte ich zu jeder anderen gewünschten Namespace-Struktur zurückkehren.

Vergessen Sie nicht, Ihr Projekt zu erstellen!

Im Fall von .NET Framework gab es im Testprojekt früher Verweise auf die folgenden DLLs:

Microsoft.VisualStudio.TestPlatform.TestFramework
Microsoft.VisualStudio.TestPlatform.TestFramework.Extentions

Ich habe sie gelöscht und einen Verweis hinzugefügt auf:

Microsoft.VisualStudio.QualityTools.UnitTestFramework

Und dann erschienen alle Tests und begannen auf die gleiche Weise wie zuvor zu arbeiten.

Ich habe fast alle anderen Vorschläge oben ausprobiert, aber das erneute Referenzieren der Test-DLLs hat in Ordnung funktioniert. Ich habe diese Antwort für diejenigen gepostet, die in meinem Fall sind.

Ich hatte in meinem Fall das gleiche Problem, um es zu lösen

1. Ich habe die Windows-Konsole geöffnet (Windows-Taste + cmd).
2. Navigieren Sie zu dem Ordner, in dem das Projekt erstellt wurde.
3. Der Befehl "dotnet test" wurde ausgeführt. Dies ist im Grunde derselbe Test, den Visual Studio ausführt. Wenn Sie ihn jedoch über die Konsole ausführen, können Sie den vollständigen Trace anzeigen.
4. Ich habe die Fehlermeldung "TestClass-Attribut für nicht öffentliche Klasse MSTest.TestController.BaseTest definiert" erhalten.
5. Also bin ich zum Testfall gegangen und habe ihn als öffentlich markiert, erneut erstellt und meine Tests werden korrekt angezeigt

Zuerst habe ich versucht, MSTest zu verwenden. Danach ändere ich es auf Nunit-Test. Dann wollte ich MSTest unterstützen. Ich habe alle nUnit-Codes und Referenzen entfernt, aber im Test Explorer wurden keine MSTest-Methoden angezeigt. Lösung: Ich habe alle mstest-Nuget-Referenzen entfernt und neu installiert. Getan.

Ändern Sie für mich das TargetFramework in der .csprojDatei des Testprojekts von

  <PropertyGroup>
    <TargetFramework>netcoreapp2.0</TargetFramework>
  </PropertyGroup>

zu

  <PropertyGroup>
    <TargetFramework>net46</TargetFramework>
  </PropertyGroup>

hat funktioniert.

In meinem Fall war das Problem, dass der Projekttyp auf statische Bibliothek (lib) gesetzt war und es sich um eine dynamische Bibliothek (dll) handeln sollte.