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


102

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)

Według Briana Harry'ego z firmy Microsoft jest to błąd, który obecnie badają. Powinien zostać naprawiony w Update 2, a tymczasowe obejście powinno zostać opublikowane później. Źródło: link
Tore Østergaard,

Mam ten sam problem dla .Net 3.5 SP1 w Visual Studio 2013 Update 5
Andrey Bushman

@AndreyBushman: Błąd może występować również w 2013U5, ponieważ został wydany razem z 2015RTM. Ale obejście powinno działać również w Twoim przypadku.
Tore Østergaard,

Miałem podobny problem, obejście polegało po prostu na vs, w ustawieniach testowych, aby wybrać właściwy domyślny procesor (32/64) bit i nie utrzymywać silnika w ruchu. (w porównaniu z 2017.x)
kfn

Odpowiedzi:


2

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


3
Cześć Patryk. Oba podane przez ciebie linki to skrzynki otwarte przeze mnie, więc nie ufałbym im jako referencji ;-).
Tore Østergaard

60

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.

Zrzut ekranu ustawień testu


To rozwiązało to dla mnie. W moim przypadku zarówno testowany projekt, jak i projekt testowy były ustawione na x86. Testy można było usunąć, ale nie udało się ich uruchomić. Po zmianie na Dowolny procesor przeprowadzono testy.
datchung

Po prostu miałem ten sam problem i to go rozwiązało. Podejrzewam również, że mogło to mieć zły nego-synergistyczny wpływ na odniesienia do głównego projektu, które nagle przestały ładować konkretną bibliotekę DLL, ale nie ustaliły ostatecznie tego nieprzyjemnego efektu ubocznego.
Allen

45

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.


10
Obecnie używam również VSTS. Zgodnie z zaleceniami dodałem NUnit3TestAdapter (ponieważ używam NUnit 3.8.1) i to rozwiązanie rozwiązało mój problem. Dziękuję :-)
Maurice Klimek

1
Install-Package NUnit3TestAdapter rozwiązał mój problem :)
Bimal Das

27

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/


3
ten sam problem był ze mną. Używam xunit z rdzeniem .net
Amna

Działało to również dla mnie w programie Visual Studio 2017 z xunit i .NET Core 2.1.
Thorkil Værge,

4
w moim przypadku był to projekt .net 4.6.1, więc jedyne, czego brakowało, to xunit runner. Zainstalowałem i działałem.
Juan

1
Tak samo jak Juan. Brakowało tylko pakietu biegacza. Uruchomienie tego w menedżerze pakietów projektu testowego rozwiązało problem: install-package xunit.runner.visualstudio
Premil

13

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.


Wpadłem na to z .Net 4.6.1 VS2017. Skończyło się na tym, że powróciłem do wersji 1.2.0 - zdecydowanie upewnij się, że nie masz dwóch różnych wersji w folderze pakietów ani w kontroli źródła.
Jeremy Thompson

2
Mój wydawał się znaleźć testy, ale tak, brak „MSTest.TestAdapter” był prawdziwym problemem. Brak ładnych błędów lub ostrzeżeń (VS2017 15.8). Wszystko wyglądało dobrze, ale nie znaleziono żadnych testów, pomimo pojawienia się w eksploratorze testów ..... Więc kiedy wykonałem polecenie „install-package MSTest.TestAdapter”, moje testy przebiegły zgodnie z oczekiwaniami. Dzięki MS - 3 godziny stracone ...........
James Joyce

1
Zainstalowanie MSTest.TestAdapter 1.4.0 zrobiło to dla mnie w VS 2019. Dzięki tobie zmarnowałem tylko 30 minut.
furman87

11

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.

Tak! I nie zapomnij o ponownym uruchomieniu programu Visual Studio. To było dla mnie wymagane.
Michael Levy

Co to znaczy „u góry menu”?
Sean Kendle

1
@SaiyajinGohan. Po wykonaniu kroku 2 zostanie wyświetlone okno „Rozszerzenia i aktualizacje”. U góry tego okna zauważyłem, że adapter NUnit jest wyłączony. Mam nadzieję, że to wyjaśnia ...
J Wood,

Dzięki za to, nadal nie mogłem pracować nad projektem, nad którym pracowałem. Na szczęście był to projekt testowy i następny zadziałał. Wciąż pozostaje tajemnicą, dlaczego.
Sean Kendle,

6

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.


5

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!

Poprawka testowa VSTS


Mój problem dotyczył (lokalnej) aktualizacji TFS 2015 Update 1 i został rozwiązany w aktualizacji 2. Nie jestem pewien, czy ten sam problem istnieje / istniał w przypadku VSTS.
Tore Østergaard

5
  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ć.

To faktycznie zadziałało dla mnie po tym, jak uderzyłem głową w tak wielu kierunkach i sugestiach.
rajibdotnet

4

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

To rzeczywiście mnie ugryzło. Myślę, że wskazówką, że tak się dzieje, jest to, że ZNAJDUJE bibliotekę DLL testów jednostkowych, ale NIE znajduje w niej żadnych testów. Odkryłem również, że umieszczenie tego w tekście po instrukcjach kopiowania pozwoli Ci sprawdzić, co zostało skopiowane (tutaj / app / tests to katalog docelowy na obrazie Dockera): RUN file = "$ (ls -al / app / tests) "&& echo $ file (zobacz ten artykuł, aby uzyskać więcej informacji na temat Echo )
David Yates

3

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


3

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


1

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.


1

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)


1

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


1

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.

wprowadź opis obrazu tutaj


1

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.


1

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 "


0

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


0

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


0

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

wprowadź opis obrazu tutaj

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.


0

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.


0

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.


0

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

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

Po pierwsze, upewnij się, że przypadek testowy można uruchomić w VS IDE.
dixiashi

0

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.


0

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


0

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


0

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>

0

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.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.