Program Visual Studio 2015 lub 2017 nie wykrywa testów jednostkowych

EDYCJA 2016-10-19:

Pierwotne pytanie dotyczyło problemu specyficznego dla VS2015 CTP6 z programem do uruchamiania testów XUnit. Z odpowiedzi jasno wynika, że ​​istnieje znacznie szerszy problem z odnajdywaniem testów jednostkowych w programie Visual Studio, który może wystąpić w wielu różnych sytuacjach. Uporządkowałem moje pytanie, aby to odzwierciedlić.

Włączyłem również skrypt do mojej własnej odpowiedzi, którego używam do dziś do rozwiązywania podobnych problemów, gdy się pojawiają.

Wiele innych odpowiedzi również okazało się pomocnych w lepszym zrozumieniu zawiłości biegacza testów VS. Doceniam, że ludzie wciąż dzielą się swoimi rozwiązaniami!

Oryginalne pytanie 10.04.2015:

Od wczoraj mój Eksplorator testów Visual Studio nie wykryje testów dla żadnego z moich projektów. Nie pokazuje również zielonego paska ładowania po zakończeniu budowy.

Kiedy przechodzę do Eksploratora testów programu Visual Studio i klikam „Uruchom wszystko” lub gdy klikam prawym przyciskiem myszy dowolną metodę testową i wybieram opcję „Uruchom testy”, w oknie danych wyjściowych pojawia się następujący komunikat:

Could not load file or assembly 'Microsoft.VisualStudio.Web.ProjectSystem, Version=14.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.

Używam Visual Studio 2015 CTP 6 na Windows 10 Pro Technical Preview, build 10041. wersja .NET Framework nie wydają się znaczenia - to dzieje się 4.0, 4.5.2i 4.6.

Wypróbowałem z następującymi frameworkami testowymi i wszystkie dają to samo zachowanie:

• Microsoft.VisualStudio.QualityTools.UnitTestFramework v14.0.22609.0
• xunit v2.1.0-beta1-build2945 z xunit.runner.visualstudio v2.1.0-beta1-build1051
• NUnit v2.6.4 z NUnitTestAdapter v2.0.0

Znalazłem problem na GitHub (xunit), który wydawał się podobny: Nie można znaleźć testów # 295 , z tym komentarzem od zespołu xunit:

Należy pamiętać, że wiele osób z testami jednostkowymi (nie tylko xUnit.net) zgłosiło, że Visual Studio 2015 CTP 5 zepsuje się, więc nie oczekuj, że to zadziała.

Ponadto upewnij się, że wyczyściłeś pamięć podręczną programu Visual Studio runner. Jeśli zostanie uszkodzony, program Visual Studio będzie trwale działać nieprawidłowo, dopóki nie zostanie usunięty. Aby wyczyścić pamięć podręczną, zamknij wszystkie wystąpienia programu Visual Studio, a następnie usuń folder% TEMP% \ VisualStudioTestExplorerExtensions (szczerze mówiąc, prawdopodobnie nie zaszkodzi usunąć wszystko w% TEMP%, które można usunąć).

Wypróbowałem ich sugestię, aby usunąć folder %TEMP%\VisualStudioTestExplorerExtensions. Niestety to nie rozwiązało problemu.

Zauważyłem, że ReSharper faktycznie jest w stanie wykryć kilka testów. Działa tylko w przypadku testów VS i NUnit, a nie xunit.

Musi istnieć jakiś folder tymczasowy lub pamięci podręcznej, który muszę wyczyścić, ale wiem, że program Visual Studio ma ich wiele i nie wszystkie można usunąć bez niepożądanych skutków ubocznych.

Ku mojemu zdziwieniu wyczyszczenie plików tymczasowych znajdujących się w %TEMP%katalogu rozwiązało problem.

Uwaga: ta ścieżka jest zwykle pod adresem C:\Users\(yourusername)\AppData\Local\Temp

Ponieważ @ Warren-P zawiera @ Warren-P, możesz przejść do folderu tymczasowego, wprowadzając %temp%menu Start lub uruchamiając „Eksplorator plików” i wpisując %temp%w pasku adresu.

Może się zdarzyć, że twój kod jest skompilowany z x64, dlatego trzeba włączyć domyślną architekturę procesora jako X64.

Test > Test Settings > Default Processor Architecture > X64

• Sprawdź, czy NUnit Test Adapter 2/3 jest zainstalowany w VisualStudio.
  (Tools>Extensions and Updates )

• Upewnij się, że wybrano właściwą architekturę procesora:
  (Test>Test Settings>Default Processor Architecture)

EDYCJA 2016-10-19 (skrypt PowerShell)

Ten problem wciąż powraca od czasu do czasu. Napisałem mały fragment programu PowerShell, aby zautomatyzować czyszczenie odpowiedniego folderu / plików pamięci podręcznej / tymczasowej. Udostępniam to tutaj dla przyszłych czytelników:

@(
"$env:TEMP"
"$env:LOCALAPPDATA\Microsoft\UnitTest"
"$env:LOCALAPPDATA\Microsoft\VisualStudio\14.0\1033\SpecificFolderCache.xml"
"$env:LOCALAPPDATA\Microsoft\VisualStudio\14.0\1033\ProjectTemplateMRU.xml"
"$env:LOCALAPPDATA\Microsoft\VisualStudio\14.0\ComponentModelCache"
"$env:LOCALAPPDATA\Microsoft\VisualStudio\14.0\Designer\ShadowCache"
"$env:LOCALAPPDATA\Microsoft\VisualStudio\14.0\ImageLibrary\cache"
"$env:LOCALAPPDATA\Microsoft\VisualStudio Services\6.0\Cache"
"$env:LOCALAPPDATA\Microsoft\WebsiteCache"
"$env:LOCALAPPDATA\NuGet\Cache"
) |% { Remove-Item -Path $_ -Recurse -Force }

Pamiętaj, aby wcześniej zamknąć program Visual Studio i prawdopodobnie dobrym pomysłem jest ponowne uruchomienie później.

Usunięcie folderu TEMP może nie być konieczne, a w niektórych przypadkach może być nawet niepożądane, dlatego radzę spróbować bez uprzedniego wyczyszczenia folderu TEMP. Po prostu pomiń "$env:TEMP".

Oryginalna odpowiedź 12.04.2015

Problem został „rozwiązany” po dokładnym wyczyszczeniu folderów temp / pamięci podręcznej związanych z programem Visual Studio.

Ponieważ nie miałem czasu, aby przechodzić przez wszystko jeden po drugim, a następnie testować pomiędzy nimi, niestety nie wiem, który z nich faktycznie spowodował problem.

Oto dokładne kroki, które podjąłem:

1. Zamknięty program Visual Studio
2. Użyto CCleaner do czyszczenia tempplików / folderów systemowych i przeglądarki

3. Ręcznie wyczyszczone / usunięte następujące pliki / foldery:

   • %USERPROFILE%\AppData\Local\assembly
   • %USERPROFILE%\AppData\Local\Microsoft\UnitTest
   • %USERPROFILE%\AppData\Local\Microsoft\VisualStudio\14.0\1033\SpecificFolderCache.xml
   • %USERPROFILE%\AppData\Local\Microsoft\VisualStudio\14.0\1033\ProjectTemplateMRU.xml
   • %USERPROFILE%\AppData\Local\Microsoft\VisualStudio\14.0\ComponentModelCache
   • %USERPROFILE%\AppData\Local\Microsoft\VisualStudio\14.0\Designer\ShadowCache
   • %USERPROFILE%\AppData\Local\Microsoft\VisualStudio\14.0\ImageLibrary\cache
   • %USERPROFILE%\AppData\Local\Microsoft\VisualStudio Services\6.0\Cache
   • %USERPROFILE%\AppData\Local\Microsoft\WebsiteCache
   • %USERPROFILE%\AppData\Local\NuGet\Cache
   • %USERPROFILE%\AppData\Local\Temp

Jednym z powodów tego problemu jest to, że Twoja klasa testowa nie jest publiczna. MSTest tylko wykrywa testy z klas publicznych.

W programie Visual Studio 2015 (Update 3), jeśli chcesz dołączyć testy w eksploratorze testów, musisz zainstalować adapter testowy NUnit. Pobierz adapter z Tools-> Extension And Updates-> Online (musisz wyszukać adapter ) -> Pobierz . Po ponownym uruchomieniu programu Visual Studio można zobaczyć zmianę dla struktury testowej.

Nie mam pełnej odpowiedzi na to pytanie, ale ustaliłem kilka rzeczy, grając z projektem testowym:

1. xunit.runner.aspnet : 2.0.0-aspnet-beta4, Który wydaje się być częścią oficjalnego wydania beta4 aspnet5 nie działa w Visual Studio.
2. Zamiast tego używanie "xunit": "2.1.0-*"i "xunit-runner.dnx": "2.1.0-*"pakiety działają w programie Visual Studio.
3. Aby VS mógł wykryć testy, Twój projekt MUSI mieć POJEDYNCZE polecenie o nazwie „test”, które uruchamia „xunit.runner.dnx”. Dodanie dodatkowych poleceń może go złamać.
4. Jeśli okno Eksploratora testów nadal jest puste, USUŃ polecenie „test” z projektu, a następnie ponownie skompiluj rozwiązanie, a następnie dodaj polecenie „test” z powrotem do pliku project.json.
5. Wyczyszczenie wszystkich pamięci podręcznych zgodnie z sugestią @ Fred-Kleuver może pomóc, ale nie wykonałem wszystkich kroków oddzielnie, więc nie jestem pewien.

Jest to aktualne zgodnie z VS 2015 CTP 6, przy użyciu wersji beta4, a nie dzienników.

Miałem przypadek, w którym niektóre testy nie zostały odebrane, ponieważ wykonałem je asyncw następujący sposób:

public async void This_IsMy_UnitTest()

Problem polegał na tym, że zapomniałem zmusić ich do zwrócenia Taska nie voidpodczas przełączania. Można by pomyśleć, że spowodowałoby to błąd lub nieudany test, ale nie. Testy jednostkowe w tej klasie zostały w pełni zignorowane i zachowywały się tak, jakby nie istniały.

Dopiero po około 3 czyszczeniach i kompilacjach + ponownym uruchomieniu VS.NETzobaczyłem uruchomienie testowe i niepowodzenie, co oznacza, że ​​zapomniałem dodać Tasktyp zwrotu:

public async Task This_IsMy_UnitTest()

Po aktualizacji testy jednostkowe zostały znalezione i działały poprawnie. Może to być przypadek skrajny, ale posiadanie asynctestów do używania awaitw środku, ale niepoprawna sygnatura, może powodować ten sam problem i nie jest to pierwszy raz, kiedy to zrobiłem.

Przejdź do menedżera pakietów Nuget i pobierz adapter Nunit w następujący sposób.

Miałem ten sam problem, ale folder „% TEMP% \ VisualStudioTestExplorerExtensions” nie istniał na moim komputerze, więc gdy czytałem posty, wpadłem na pomysł, aby go utworzyć i działa. Eksplorator testów może teraz wyświetlić wszystkie moje testy. Dzięki.

Po prostu uruchom ponownie program Visual Studio iw Eksploratorze testów wykonaj „Uruchom wszystko” ... Wszystkie moje testy zostaną wtedy wykryte.

W moim przypadku (Visual Studio Enterprise 2015 14.0.25425.01 Update 3, Resharper 2016.2) po prostu potrzebowałem zrobić czyste rozwiązanie z menu Build. Odbudowanie rozwiązania powoduje, że eksplorator testów „wybudzi się” i ponownie znajdzie wszystkie testy.

Rozwiązaniem w moim przypadku było po prostu zainstalowanie rozszerzenia NUnit 3 Test Adapter do mojego programu Visual Studio 2015.

W moim przypadku problem był „między krzesłem a klawiaturą”. Przełączyłem się do konfiguracji w menedżerze konfiguracji, która nie zawierała moich projektów testów jednostkowych w kompilacji. Powrót do konfiguracji (np. Debugowania) obejmującej wszystkie projekty rozwiązało problem.

W moim przypadku MSTest pod VS 2015 ignorował testy z nazwami testowymi (tj. Metod), które były dłuższe niż 174 znaki. Skrócenie nazwy umożliwiło wyświetlenie testu. Zostało to ustalone przez zgadywanie i sprawdzanie, manipulując nazwą testu.

Prawdopodobnie nie pomoże to większości ludzi, ale ktoś niedoświadczony w testowaniu jednostkowym napisał metodę testową, która zwróciła boolzamiast void:

[TestMethod]
public bool TestSomething()

Zmiana typu zwrotu w celu voidrozwiązania problemu.

Upewnij się, że masz xunit.runner.visualstudiopakiet w swoim projekcie testowym packages.config i że został on poprawnie przywrócony.

Wiem, że tak nie było w pierwotnym pytaniu, ale może to zaoszczędzić czas komuś takiemu jak ja.

Dodam tylko, że znalazłem zupełnie inne rozwiązanie niż powyższe.

Zadeklarowałem moją klasę testową jak poniżej:

[TestClass]
class ClassificationTests
{
   //unit tests
}

Jak tylko dodałem publicmodyfikator do klasy, działał zgodnie z oczekiwaniami!

Jeśli celujesz w .NET Standard lub .NET Core, musisz użyć pakietu NuGet dla adaptera testowego NUnit, a nie rozszerzenia .

W przypadku testowania projektów .NET Core lub .NET Standard zaleca się zainstalowanie adaptera z programu NuGet. Adapter VSIX nie obsługuje i nie będzie obsługiwać platformy .NET Core, ponieważ pakiety VSIX nie mogą być przeznaczone dla wielu platform.

Źródło: NUnit GitHub Wiki

.

Sprawdź również FAQ tam:

Moje testy nie pojawiają się w programie Visual Studio 2017?

• Czy używasz pakietu NuGet?
• Czy używasz wersji 3.8.0 lub nowszej pakietu NuGet?
• Czy Twoje testy są ukierunkowane na platformę .NET Core czy pełną wersję .NET Framework? (patrz wyżej)
• Czy dodano odwołanie do pakietu do Microsoft.NET.Test.Sdk?
• Czy uruchomiłeś ponownie program Visual Studio? Nadal jest trochę temperamentny.

Źródło: NUnit GitHub Wiki

Zdarzyło mi się to, ponieważ mój projekt testowy zawierał plik app.config. Został automatycznie dodany przez pakiety NuGet w celu przekierowania zestawu, ale moje testy wydawały się działać bez niego.

Zobacz: https://developercommunity.visualstudio.com/comments/42858/view.html .

Miałem ten sam problem. Właśnie wyczyściłem i przebudowałem projekt i mogłem zobaczyć brakujące testy.

Wpadłem, żeby podzielić się moim rozwiązaniem. Pracowałem na systemie Windows 10, Visual Studio 2015, NUnit 3.5, NUnit Test Adapter 3.6 (przez NuGet, a nie rozszerzenie VISX) i żaden z moich testów nie został wykryty. Mój problem polegał na tym, że w projekcie Testy mojego rozwiązania w jakiś sposób został utworzony skrót do mojego folderu „Dokumenty” w folderze projektu. Domyślam się, że adapter testowy widział skrót i rozłączał się, próbując dowiedzieć się, co z nim zrobić, co spowodowało niepowodzenie w wyświetlaniu testów jednostkowych.

Usunięcie pliku \ AppData \ Local \ Microsoft \ VisualStudio \ 14.0 \ 1033 \ SpecificFold‌ erCache.xml rozwiązało problem.

Ten temat jest nieco przestarzały, ale moje rozwiązanie braku statusu testu w VS2015:

Stan zadania jest wyświetlany tylko w konfiguracji kompilacji debugowania. Oczywiście uniemożliwia to również debugowanie testu za pomocą eksploratora testów.

Ugryzła mnie też ta cudowna mała cecha i nic tu opisanego nie zadziałało. Dopiero dwukrotnie sprawdziłem wyniki kompilacji i zauważyłem, że odpowiednie projekty nie były budowane. Wizyta u menadżera konfiguracji potwierdziła moje podejrzenia.

Visual Studio 2015 szczęśliwie pozwolił mi na dodanie nowych projektów, ale zdecydował, że nie warto ich budować. Kiedy dodałem projekty do kompilacji, zaczęło ładnie grać.

Rozwiązałem to, zmieniając X64 na: Kliknij prawym przyciskiem myszy projekt -> Właściwości -> Kompiluj -> Cel platformy -> Dowolny procesor

W jakiś sposób mój projekt został skonfigurowany do kompilacji jako biblioteka statyczna (.lib) . Po zmianie tego na bibliotekę dynamiczną (dll) testy zostały poprawnie wykryte przez program Visual Studio 2012.

My Unit Test Project ->
Properties ->
Configuration Properties ->
General ->
Configuration Type

Naprawienie tego problemu było tak łatwe, jak:

• Wybierz projekt testu jednostkowego
• Kliknij przycisk „Pokaż wszystkie pliki” w Eksploratorze rozwiązań, aw drzewie plików Eksploratora rozwiązań w obszarze „obj \ x86 \ Debug” pojawiły się nowe pliki tymczasowe.
• Usuń te pliki tymczasowe i odbuduj projekt.
• Ponownie próbowałem uruchomić testy i zadziałało !.

Mieliśmy ten sam problem. Mamy duże rozwiązanie VS 2015 z wieloma projektami C # i jeszcze większą liczbą projektów testowych.

Odkrycie testowe Resharper działało dobrze, ale VS Test Explorer nie powiodło się.

Okazuje się, że projekty nie miały tej samej wersji MsTest TestFramework i TestAdapter, a czasami korzystały z NuGets, a innym razem dobrych starych referencji, a to najwyraźniej nie jest obsługiwane (tak bardzo jak na tak drogie IDE).

Usunięcie wszystkich odwołań do Microsoft.VisualStudio.Test *, a następnie dodanie / zaktualizowanie dwóch MSTest NuGets rozwiązało problem.

Rozwiązałem ten problem, zdając sobie sprawę, że ramy docelowe mojego projektu testowego były inne niż projekt testowany. Tak, spowodowałem ten problem, zmieniając docelową strukturę z domyślnej (Projekt> Właściwości> Aplikacja), ale nie udało mi się to w przypadku projektu testowego, który został utworzony kilka tygodni później. Niezgodność nie spowodowała błędu kompilatora, ale spowodowała ostrzeżenie w oknie Lista błędów . Gdy wybrałem opcję wyświetlania ostrzeżeń, rozwiązanie było oczywiste.