Nie znaleziono testu. Upewnij się, że zainstalowane narzędzia do wykrywania i wykonywania testów, ustawienia wersji platformy i frameworka są odpowiednie i spróbuj ponownie

Jestem w trakcie uaktualniania naszego istniejącego rozwiązania do .Net 4.6.1 i nie mogłem uruchomić naszych testów jednostkowych podczas kompilacji serwera. Lokalnie działają zgodnie z oczekiwaniami, a zmiana wersji frameworka z powrotem na .Net 4.5.1 powoduje ich ponowne uruchomienie na serwerze.

Otrzymuję następujący błąd:

Nie znaleziono testu. Upewnij się, że zainstalowane narzędzia do wykrywania i wykonywania testów, ustawienia wersji platformy i frameworka są odpowiednie i spróbuj ponownie.

Odtworzyłem problem w prostszej konfiguracji:

• Rozwiązanie z jednym projektem testów jednostkowych języka C # z dwoma testami (jeden zakończony niepowodzeniem, jeden pomyślny).
• Definicja kompilacji XAML przy użyciu szablonu domyślnego (TfvcTemplate.12.xaml)
• Serwer kompilacji TFS 2015 Update 1 XAML z zainstalowanym programem Visual Studio Enterprise 2015 Update 1 (ma sześć podobnych serwerów i wszystkie dają ten sam wynik)

Jest to obecnie znany problem dotyczący platformy .Net 4.6.

Nie można uruchomić testów jednostkowych .Net 4.6.x w ramach kompilacji XAML TFS z aktualizacją TFS 2015 UPdate1 Źródło: https://connect.microsoft.com/VisualStudio/feedback/details/2245723

Oto podobne pytanie do odniesienia: nie można uruchomić testów jednostkowych .Net 4.6 serwera kompilacji XAML TFS 2015

Możesz spróbować zmienić domyślną architekturę procesora w ustawieniach testowych z X86 na X64. W moim przypadku to był problem.

Dzieje się tak, jeśli platforma docelowa testowanego projektu jest ustawiona na x64.

Moja kompilacja też nie znalazła testów. Moja konfiguracja i rozwiązanie do znajdowania testów są następujące.

Używam VSTS (Visual Studio Team Services) i mam kompilację skonfigurowaną do odświeżania pakietów NUGET w każdej kompilacji. Używam NUnit i stwierdziłem, że uruchomienie następującego polecenia NUGET (z konsoli menedżera pakietów w programie Visual Studio) w celu dodania biblioteki NUnitTestAdapter do mojego projektu testowego i sprawdzenie w pliku packages.config spowodowało uruchomienie testów w mojej kompilacji VSTS.

Install-Package NUnitTestAdapter

Jak Maurice wspomina w komentarzu do tego postu dla NUnit3 użyj następującego pakietu NUGET (poszukaj innych narzędzi w linku, tj .: dotnet CLI i Paket CLI)

Install-Package NUnit3TestAdapter

Mam nadzieję że to pomoże.

W moim przypadku musiałem:

1. Konwertuj projekt testowy na netcore 2.0 (poprzednio netstandard 2.0)

2. Dodaj pakiet NuGet xunit.runner.visualstudio

Źródła: http://www.neekgreen.com/2017/11/20/xunit-no-test-is-available/

Używam MSTest. Dla mnie była to niezgodność wersji i brak innego pakietu zależnego -

1) Mój folder z pakietami zawiera tylko pakiet MSTest.TestFramework.1.2.1. W moim pliku projektu (.csproj) odwołaniem w Nazwa docelowa był pakiet MSTest.TestAdapter.1.2.0, którego nie było w folderze pakietu. Moje packages.config ma również odniesienie do MSTest.TestFramework.1.2.0.

2) Więc zainstalowałem MSTest.TestAdapter.1.2.0 z menedżera pakietów NuGet i wyrównaj wersję MSTest.TestFramework do 1.2.0 w projekcie i pliku pakietu. Na koniec dodaję Microsoft.VisualStudio.TestPlatform.TestFramework i Microsoft.VisualStudio.TestPlatform.TestFramework.Extensions w referencji.

Wtedy wszystko było w porządku. Mam nadzieję, że to komuś pomoże.

Otrzymałem ten błąd i udało mi się go rozwiązać.

1. Używam Visual Studio Professional 2017
2. W VS przeszedłem do Narzędzia -> Rozszerzenia i aktualizacje
3. U góry menu zauważyłem, że mój adapter NUnit jest wyłączony
4. Kliknąłem przycisk [Włącz]
5. Udało mi się rozpocząć testy bez błędów.

Ten problem pojawia się ponownie dla programu Visual Studio 2017. Najprawdopodobniej kolejny błąd, ale ten sam wynik.

Jednym z obejść, które wydaje się działać, jest odinstalowanie zdalnego debugera programu Microsoft Visual Studio 2017 z komputera, którego dotyczy problem.

Napotkałem ten sam problem w VSTS z .Net 4.6.2. Jeśli widzisz to na wyjściu konsoli VSTS, obejście dostarczone przez @Sushil nadal działa w VSTS i jest potrzebne. Niestety zadanie „Test Assemblies” dostarczone przez Microsoft kończy się powodzeniem, więc tak naprawdę nie wiesz nawet, że jest problem, chyba że sprawdzisz dane wyjściowe i nie stwierdzisz, że żaden z testów nie został faktycznie wykonany!

1. Zainstaluj najnowszą wersję Nunit i NUnitTestAdapter z pakietu NUGET.
2. Przejdź do -> Test -> Ustawienia testowe -> Domyślna architektura procesora -> Zmień na X64
3. Zbuduj rozwiązanie.
4. Spowoduje to rozwiązanie problemu z uruchomieniem testu i debugera w testach jednostkowych i zacznie działać.

Jeśli uruchamiasz testy wewnątrz platformy docker przy użyciu kompilacji wieloetapowej, a testy nie zostaną znalezione. Upewnij się, że kopiujesz wszystkie pliki, a nie tylko pliki projektu, jak poniżej sekcja 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

Naprawiłem ten problem w projekcie testowym VS 2017 i 4.6.2, wykonując następujące kroki:

1. Usuń odniesienia do Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll i rozszerzeń
2. Zainstaluj pakiet Microsoft.VisualStudio.QualityTools.UnitTestFramework.Updated nuget

Upewnij się, że masz zainstalowany nuget „Microsoft.NET.Test.Sdk”.

Naprawiłem ten problem poprzez ponowne zainstalowanie wszystkich badań związanych pakiety Nuget dla projektu: Xunit, Xunit.runner.vistualstudio,Microsoft.Net.Test.Sdk

Otrzymałem podobny problem i zauważyłem, że w jakiś sposób app.configplik został dodany do mojego projektu testowego. Usunięcie tego pliku konfiguracyjnego naprawiło to za mnie.

Korzystając z platformy .Net Core z potokiem kompilacji w programie TFS 2017, mój krok testowy programu Visual Studio przebiegał pomyślnie bez wykonywania żadnych testów. Musiałem edytować krok „Zaawansowane opcje wykonywania” -> „Inne opcje konsoli”, aby uwzględnić:

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

(To pole zawiera również /platform:x64)

Wystąpił ten błąd, ponieważ moja klasa testów jednostkowych nie była publiczna.

Dawny:

class ClientTests

Błąd w danych wyjściowych:

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

Korekta:

public class ClientTests

Wyrzucę moje rozwiązanie na stos. W moim przypadku dodaję kilka projektów do istniejącego rozwiązania wraz z projektami testowymi dla nich. Używamy MSTest. W rozwiązaniu, które powodowało problemy ze zgodnością, włączono poprzedni plik UnitTest.testsettings.

Kliknięcie pliku ustawień usunęło sprawdzenie, a uruchomienie testowe zakończyło się pomyślnie dla moich testów.

Znalazł sposób! Chyba nie najbardziej ortodoksyjny, ale pomógł mi w pośpiechu:

1. Zaktualizuj pakiety MSTest.TestAdapter i MSTest.TestAdapterFramework do wersji 1.4.0 z narzędzia> Menedżer pakietów NuGet.
2. Oczyść roztwór i ponownie przeprowadź testy.

Nie sądzę, aby była to cokolwiek szczególnego w tej wersji, ale jej aktualizacja z pewnością usuwa wszelkie odniesienia, które są złe w rozwiązaniu / projekcie.

Używam MSTest.

Zainstalowałem z Nuget najnowszą wersję MSTest.TestFramework i zastąpiłem OOB Usuń odniesienia do Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll

Następnie zainstalowano z Neget najnowszą wersję Microsoft.TestPlatform

Pozwoliło mi to uruchomić test poleceniem:

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

Ale mam ten sam błąd. Główna przyczyna błędu polegająca na tym, że nie określiłem adaptera testowego, który analizuje zestaw i znajduje testy.

Rozwiązanie:

1. Zainstaluj pakiet NuGet „MSTest.TestAdapter”

2. Określ adapter testowy na końcu polecenia:

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

To tylko podsumowanie rozwiązania przedstawionego wcześniej przez @Sushil.

Jest to znany problem występujący w Team Foundation Server 2015 RTM + Update 1 i zostanie rozwiązany w aktualizacji 2, odniesienie .

Jest obejście opisane przez @Sushil tutaj , które obejmuje dodanie pliku .runsettings, który wymusza uruchomienie testera na starszym frameworku .Net (proszę nie musieć go określać w oknie dialogowym "Dodaj / Edytuj przebieg testu" jako dodanie w edytorze procesu budowania zostaną zignorowane).

W Visual Studio 2017 po prostu odinstalowuję i ponownie instaluję NUnitTestAdapter lub instaluję nowy pakiet, taki jak pakiet NUnitTestAdapter.WithFramework i problem zniknął.

Mam ten sam problem. Używam programu Visual Studio 2017 Community Edition.

Wykonałem następujące kroki, aby pomyślnie wykryć wszystkie moje przypadki testowe i pomyślnie je uruchomić:

• Najpierw przejdź do Rozszerzenia i aktualizacje, zainstaluj adapter testowy NUnit3. Jeśli już masz, po prostu go włącz.

• Uruchom ponownie program Visual Studio 2017, automatycznie wyświetli się monit o
  zainstalowanie rozszerzenia. Jeśli pojawi się monit o zakończenie zadania, aby kontynuować
  instalację, po prostu kliknij „Zakończ zadanie”.

• Następnie odbuduj projekt testowy, a wszystkie przypadki testowe zostaną zidentyfikowane i możesz teraz rozpocząć uruchamianie przypadków testowych.

W moim przypadku ponowna instalacja adaptera Nunit3, usuwanie folderów tymczasowych, zmiana architektury i nic nie działało. To z powodu Daemon Resharper, który spowodował problem.

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

To rozwiązuje problemy.

Ten błąd może wystąpić w przypadku testów asynchronicznych, jeśli masz nieprawidłowy typ zwrotu. Typ zwracany powinien mieć wartość Task, a nie void.

Po dodaniu TestAdapterPath w Commander, to zadziałało:

vstest.console.exe Xom.Gci.Lvf.FileParserInvoker.UnitTests.dll /TestAdapterPath:"C:\****\****\{SolutionFolder}"

W moim przypadku testy zostały wykryte, ale ich uruchomienie zakończyło się komunikatem „Test niedostępny ... ” i (nie) sławny: „Upewnij się, że wykrywacz testów i programy wykonawcze są zarejestrowane, a ustawienia wersji platformy i frameworka są odpowiednie i spróbuj ponownie”.

błąd był niezależny od programu Visual Studio (testowany z narzędzi dotnet CLI i prawie nagiego testu UNit) i występował tylko w przypadku platformy .NET 4.7.1. Aplikacja dotnetcore działa dobrze.

również uruchomienie testów z Nuint3 CLI nunit3-console.exe Tests.csprojpokazuje błąd:

„Albo zespół nie zawiera testów, albo nie znaleziono odpowiedniego sterownika testowego”.

błąd wynikał z tego, że adapter testowy nie mógł zostać znaleziony na (zmapowanym) dysku sieciowym lub udziale i został rozwiązany przez skopiowanie go lokalnie i ponowne uruchomienie.

Spróbuj uruchomić vstest.console.exez --diag:diag.txti sprawdzić wyjście. Dla mnie były to błędy ładowania DLL dla adapterów testowych z mojego katalogu roboczego:

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.

Pracowałem wokół to poprzez dodanie <loadFromRemoteSources enabled="true"/>mocy <runtime>w vstest.console.exe.config

Napotkałem podobny problem, gdy wypróbowałem nUnit w VS 2017 i nie jest to główny projekt. Instalacja NUnit3TestAdapterrozwiązała problem.

Rozwiązałem ten problem, instalując NUnit3TestAdapter NuGet w moim projekcie ( https://www.nuget.org/packages/NUnit3TestAdapter/ ).

dotnet add package NUnit3TestAdapter --version 3.17.0

Mój plik .csproj

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>netcoreapp3.1</TargetFramework>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Microsoft.NET.Test.Sdk" Version="16.7.1" />
    <PackageReference Include="NUnit" Version="3.12.0" />
    <PackageReference Include="NUnit3TestAdapter" Version="3.17.0" />
    <PackageReference Include="RestSharp" Version="106.11.7" />
  </ItemGroup>

</Project>

To pytanie jest oczywiście zadawane przez osoby z różnymi scenariuszami, moja odpowiedź obejmie uruchamianie testów XUnit w projekcie .NET Core przy użyciu potoku kompilacji w Azure DevOps, ale może też pomóc innym.

• Upewnij się, że masz zainstalowane karty testowe XUnit z NuGet zgodnie z tą odpowiedzią .
• W YAML dla budowy rurociągu, dodać otherConsoleOptions: '/framework:.NETCoreApp,Version=v3.1'do inputsswojego VSTest@2etapu (z numerem wersji zestawu do dowolnej wersji .NET Rdzenia używasz). Więcej informacji można znaleźć w tej dokumentacji .
• Chociaż nie jest to obowiązkowe, zalecałbym również dodanie, failOnMinTestsNotRun: trueaby potok kompilacji zgłosił błąd, jeśli zostaną uruchomione testy zerowe.
• Jeśli uruchomisz kompilację w tym momencie, może się okazać, że testy są uruchamiane, ale potok wyświetla błąd The library 'hostpolicy.dll' required to execute the application was not found. Możesz rozwiązać ten problem, zmieniając filtr z domyślnego **\*test*.dllna **\*test.dll(zwróć uwagę na usuniętą gwiazdkę) lub inny wzorzec, który będzie pasował do biblioteki DLL projektu testowego. Powodem tego jest to, że XUnit umieszcza plik o nazwie testhost.dllw katalogu wyjściowym, jak wyjaśniono w tym wydaniu na githubie .

Jeśli używasz starszych potoków, które nie używają yaml, powinny być dostępne te same opcje. Ta odpowiedź obejmuje dodanie frameworka, zakładam, że będzie również opcja „Zaliczenie zadania, jeśli minimalna liczba testów nie zostanie uruchomiona” lub coś podobnego.