Walczę z VS 2017, odkąd go zainstalowałem. Teraz wydaje się, że testy jednostkowe będą uruchamiane tylko z wiersza polecenia „test dotnet”.

Mój projekt to .NET Core 1.1.1. Mam zainstalowany pakiet SDK i aktualizację środowiska dla wersji 1.1.1.

Próbowałem próbkę w MSDN ( https://msdn.microsoft.com/en-us/library/ms182532.aspx ), który również zawodzi dokładnie w ten sam sposób.

Wszystkie pakiety NuGet do testów i głównego projektu są aktualne. Zarówno projekt testowy, jak i projekt główny budują się bez błędów. Testy przebiegają pomyślnie z wiersza poleceń.

Czy ktoś przeprowadził testy jednostkowe w VS 2017, jeśli tak, to w jaki sposób?

Dzięki, John

Aktualizacja - przedłuż

Oto przykład prostego projektu testowego, który nie działa w GitHub . To jest przykład z xUnit, ale wypróbowałem NUnit i studio graficzne wbudowane w testy MS. Bez względu na to, jakie testy lub jakie zmiany wprowadzę, nie mogę zmusić programu testującego VS do znalezienia jakichkolwiek testów.

Co próbowałem

• Usuwanie plików testowej pamięci podręcznej VS DEL %TEMP%\VisualStudioTestExplorerExtensions
• Ponowne uruchamianie VS
• Eksplorator testu zamknięcia / otwarcia
• dla zainstalowanego xUnit Microsoft.DotNet.InternalAbstractions( patrz post SO )
• w przypadku NUnit upewnij się, że zainstalowano adapter i tę samą wersję (3) co pakiet NUnit
• test -> test settings -> default processor architecture jest ustawiony na x86

Pytanie
Czy każdy może podać działający przykład rozwiązania .Net Core 1.1.0 w VS2017 (pliki projektu .csproj), w którym eksplorator testów VS pomyślnie znajduje testy jednostkowe LUB pokazuje mi problem w podanym przykładzie.

W moim przypadku okazało się, że po prostu musiałem zaktualizować moje adaptery testowe i platformę testową. Gotowe.

Przykład użycia Menedżera pakietów NuGet:

To po prostu zadziałało dla mnie (nie wiem, czy to wynik zmiany przestrzeni roboczej, która coś zepsuła):

Usuwanie plików testowej pamięci podręcznej VS w% TEMP% \ VisualStudioTestExplorerExtensions i zrestartowanie VS2017.

Interfejs API dla adapterów testowych dla platformy .NET Core zmienił się wraz z wydaniem programu Visual Studio 2017 i przejściem z project.jsonformatu do csprojformatu. To sprawiło, że istniejące dotnet-test-*adaptery stały się dotnet-test-nunitprzestarzałe.

Adaptery zostały zaktualizowane, ale sposób instalacji i uruchamiania testów w Visual Studio lub w wierszu poleceń dotnet testwymaga różnych odniesień w projektach testowych. Uważaj na wszelkie dokumenty, które znajdziesz w tych pakietach referencyjnych w dotnet-test-*formacie, ponieważ są one nieaktualne.

Po pierwsze, projekt testowy musi być ukierunkowany na konkretną platformę .NET Core lub .NET Framework. Nie można kierować na .NET Standard, nawet jeśli testowany kod to .NET Standard. Wynika to z faktu, że cel testów wskazuje, na której platformie uruchomić testy. .NET Standard przypomina PCL (Portable Class Library), ponieważ może działać na wielu platformach.

Następnie musisz dodać odniesienia do Microsoft.NET.Test.Sdkwybranej struktury testowej i kompatybilnego adaptera testowego. W przypadku NUnit referencje będą wyglądać następująco:

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

Powyższy komentarz wspomina o dodaniu,

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

Nie jest to bezwzględnie wymagane, ale może pomóc. Jest on automatycznie dodawany do wszystkich projektów testów jednostkowych przez Visual Studio, aby pomóc mu szybko znaleźć projekty z testami.

Jeśli testy nie pojawiają się w programie Visual Studio, pierwszą rzeczą do wypróbowania jest zamknięcie rozwiązania, a następnie ich ponowne otwarcie. Wygląda na to, że w programie Visual Studio występują błędy, które nie wykrywają zmian w projektach podczas ich edycji.

Aby uzyskać więcej informacji, zobacz Testowanie .NET Core za pomocą NUnit w Visual Studio 2017

Miałem ten sam problem i uruchomiłem go, wykonując następujące czynności:

• Najpierw zamknij wszystkie otwarte instancje Visual Studio i usuń ten folder:% TEMP% \ VisualStudioTestExplorerExtensions. ( Uruchamianie testów w Visual Studio )
• Przejdź do menedżera pakietów Nuget i zainstaluj najpierw Microsoft.NET.Test.Sdk (15.3.0-Preview-20170425-07), a następnie zainstaluj xunit.runner.visualstudio (2.3.0-beta1-build1309). Zobacz dołączony zrzut ekranu Nuget, aby zobaczyć wszystkie pakiety, które musiałem zainstalować, aby uzyskać najnowszą wersję VS 2017 do wykrycia moich testów.

Zapomnienie o upublicznieniu klasy testowej uniemożliwia odkrycie metod testowania

Miałem domyślny projekt xUnit i usunąłem przykładowy UnitTest1.cs, zastępując go klasą testów kontrolera, kilkoma testami, ale żadnego nie znaleziono

Krótko mówiąc, po aktualizacji pakietów xUnit, Test.Sdk, xUnit.runner i przebudowaniu projektu napotkałem błąd kompilacji:

Błąd xUnit1000 Klasy testowe muszą być publiczne

Na szczęście zaktualizowana wersja rzuciła ten wyjątek, aby zaoszczędzić mi trochę kłopotów

Modyfikacja klasy testowej, aby była publiczna, naprawiła mój problem

W moim przypadku kieruję projekt testowy na x64Architektura, a ustawienie testu Architektura (test-> Domyślna architektura procesora) zostało zmienione na x86. Nie pasowały.

Po zresetowaniu ustawienia testu Architektura x64i przebudowanie wszystkich testów zostały ponownie odkryte.

Miałem problem z tym, że VS 2017 również znalazł mój UnitTest. To nie był dokładnie problem, o który pytał John - ale był to pierwszy wynik w Google, którego szukałem, więc chciałem podzielić się moim problemem.

Miałem starsze rozwiązanie wracające z VS2010 w porównaniu z VS2013, VS2015. Teraz w VS2017 wydaje się, że przestrzenie nazw dla [TestMethod]atrybutu uległy zmianie.

Przed użyciem

Microsoft.VisualStudio.QualityTools.UnitTestFramework, Version=10.0.0.0

W projekcie utworzyłem nowy Test.dll, który jest domyślnie używany

Microsoft.VisualStudio.TestPlatform.TestFramework, Version=14.0.0.0

Więc moim rozwiązaniem było stworzenie nowego projektu UnitTest z poziomu VS2017. Być może działałoby również zmiana odniesień do zestawu dla starego projektu testowego. Dzięki nowej referencji VS2017 odkrył te testy jednostkowe.

Nie czytaj nieaktualnych artykułów w MSDN. Odpowiednie materiały .NET Core znajdują się pod docs.microsoft.com

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

Ogólnie rzecz biorąc, potrzebujesz aplikacji konsoli .NET Core do przechowywania przypadków testowych.

dla mnie problemem było to, że omyłkowo umieściłem testery w klasie wewnętrznej

[TestClass]
  internal class TestLib {
}

powodowało to, że przypadki testowe nie zostały zidentyfikowane.

Upewnij się, że używasz prawidłowego Microsoft.NET.Test.Sdk:

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

Nie używaj wersji wstępnej. Lub musisz przejść do aplikacji konsoli (nie biblioteki). Mam podobny problem, ale w najnowszej wersji (15.0.0) znów zaczyna działać.

Ponadto może być konieczne dodanie:

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

ale nie sądzę, żeby było to konieczne.

Wiem, że OP umieścił to na swojej liście kontrolnej, ale łatwo przeoczyć ten punkt, wykonując czystą instalację programu Visual Studio 2017 i konfigurując nowy projekt. Oprócz szablonu projektu NUnit i NUnit Framework należy osobno zainstalować adapter NUnit, np. Za pomocą polecenia NuGet Install-Package NUnit3TestAdapter -Version 3.9.0. Po tym Visual Studio Community 2017 zaczął odkrywać testy jednostkowe bez żadnych problemów.

W moim przypadku Eksplorator testów nie mógł znaleźć moich testów po przeniesieniu projektu do nowego rozwiązania.

Odpowiedź brzmiała po prostu, że miałem odniesienie do starego MS Test Adaptera w moim projekcie.

W moim pliku cs.proj miałem duplikat poniższej linii dla wersji 1.1.11 MS Test Adapter:

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

Naprawić problem,

1. Kliknij projekt prawym przyciskiem myszy i wybierz „Rozładuj projekt”.
2. Kliknij projekt prawym przyciskiem myszy i wybierz „Edytuj”
3. Usuń wiersz importujący starą wersję adaptera.
4. Kliknij projekt prawym przyciskiem myszy i wybierz opcję „Załaduj ponownie projekt”.
5. Przebuduj rozwiązanie / projekt

Właśnie miałem ten problem z tym, że studio wizualne nie było w stanie znaleźć moich testów, nie widziałem przycisku, aby je uruchomić oprócz metody, i nie zostały wykryte przez uruchomienie wszystkich testów w projekcie.

Okazało się, że moja klasa testowa nie była publiczna! Upublicznienie pozwoliło VS odkryć testy.

Dla mnie łatwiej było stworzyć nowy projekt testowy, który działa idealnie dobrze z Visual Studio 2017 ... i po prostu skopiować pliki testowe, dodać odniesienia i pakiety NuGet zgodnie z wymaganiami.

W moim przypadku był to projekt, który uaktualniłem projekt testowy z wcześniejszej wersji .Net. w app.config miałem powiązania zestawu z poprzednimi wersjami zależnych zestawów.

Po naprawieniu assemblenbindings w app.config moje testy zostały odkryte.

Odkrycie

Powyższe najważniejsze odpowiedzi nie działały dla mnie (restartowanie, aktualizacja do wersji 1.1.18 ... Byłem już zaktualizowany, usuwanie plików tymczasowych, czyszczenie pamięci podręcznej NuGet itp.).

Odkryłem, że miałem różne odniesienia do MSTest.TestAdapter i MSTest.Framework w różnych projektach testowych (moje rozwiązanie ma dwa). Jeden wskazywano na 1.1.18 jak ...

Package.config

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

... ale inny zawiera odniesienia do 1.1.11. Niektóre z powyższych odpowiedzi prowadzą do tego odkrycia, gdy dwie wersje bibliotek pojawiły się w moim katalogu tymczasowym (% TEMP% \ VisualStudioTestExplorerExtensions \) po ponownym uruchomieniu programu Visual Studio.

Rozwiązanie

Właśnie aktualizacja mojego Package.config do wersji 1.1.18 przywróciła moją funkcjonalność testów jednostkowych w VS. Wygląda na to, że istnieją pewne błędy, które nie pozwalają na bezpośrednie odniesienia do bibliotek MSTest. Mam nadzieję, że to ci pomoże.

Więcej informacji:

• Visual Studio 2017 Ent: 15.5.6 (zaktualizowałem wersję 15.0.1 z nadzieją, że naprawię ten problem, ale miałem go w obu)

Rozwiązaniem było usunięcie mojego app.configpliku z mojego projektu testu jednostkowego. Testy pojawią się ponownie!

Ten plik odwoływał się do niektórych bibliotek dll w powiązaniach redirect, które w rzeczywistości nie były obecne w odwołaniach do projektu. Ponownie dodaj wiązania zespołu, które są absolutnie niezbędne dla twojego projektu.

W moim przypadku przyczyną problemu był projekt UWP obecny w rozwiązaniu.

Kiedy wyładowałem projekt UWP, odkryto testy. Po ponownym załadowaniu test ponownie zniknął.

Spróbuj rozładować wszystkie projekty i zachowaj tylko projekt testowy. Dziesięć przebudowanych rozwiązań i testów pojawi się w Test Runner. Załaduj projekty jeden po drugim i za każdym razem przebuduj rozwiązanie, aby dowiedzieć się, który projekt powoduje problem

przykładowe repozytorium

Raport o błędzie VS

Problem

Problem polega na tym, że program Visual Studio jest „zdezorientowany” w stosunku do podstawowych wersji dotnet na komputerze. Kiedy poszedłem do panelu sterowania -> odinstaluj programy, miałem 8 różnych zestawów SDK i środowisk uruchomieniowych dotnet core. To w jakiś sposób powodowało, że VS po cichu miał błąd podczas próby znalezienia testów.

Zatwierdź problem

Możesz zweryfikować problem, przechodząc do wiersza poleceń i wybierając wersję dotnet $ dotnet --version. Jeśli widzisz cokolwiek poza zainstalowaną najnowszą wersją, oznacza to, że twój komputer jest trochę niezgodny i nie używa prawidłowej wersji. Przykład ... Jeśli masz 1.0.1zainstalowany rdzeń dotnet, ale gdy dostaniesz wersję w wierszu polecenia i pojawi się komunikat, że 1.0.0to problem.

Rozwiązanie

Usuń wszystkie stare rzeczy. Zacząłem od tego, co musiałem usunąć (najstarsze wersje dotnet rc), ale nadal dawało złą wersję podczas testowania problemu. W końcu przyznałem się do pełnego czyszczenia. JA...

• Odinstalowałem wszystkie aplikacje Visual Studio (na moim komputerze VS2015 i VS2017)
• Odinstalowano wszystkie wersje rdzenia dotnet (nawet najnowsze)

Po tym, jak moja maszyna była całkowicie pusta ze wszystkich VS i nie zainstalowałem tylko VS2017 (jest dostarczany z najnowszą wersją dotnet). Stworzyłem projekt testowy xUnit, a eksplorator testów znalazł test natychmiast ROZWIĄZANY

To może wydawać się przesadą, ale spędziłem dwa tygodnie próbując naprawić to na inne sposoby. Jeśli masz problem, po prostu to zrób, nawet jeśli odinstalowanie / ponowne zainstalowanie elementów może zająć wiele godzin, prawdopodobnie zaoszczędzisz czas.

Bibliografia

• Zobacz post na blogu @epestic, w którym podano więcej szczegółów na temat rozwiązania problemu.

Próbowałem wszystkiego, ale nic nie pomogło. W moim przypadku miałem rozwiązanie z kilkoma projektami testowymi, a niektóre z nich używały starej struktury ms-test, więc Visual Studio znalazł tylko te.

Zainstalowałem pakiety ram testowych dla wszystkich projektów testowych, jak pokazano w zaakceptowanej odpowiedzi . Następnie usunąłem odwołania do starych narzędzi jakości, ponownie uruchomiłem Visual Studio i teraz widzę wszystkie testy.

Dla C ++:

Ponieważ nie ma specjalnego pytania dla testów C ++, ale temat jest bardzo ten sam, oto co pomogło mi, gdy miałem problemy z wykrywaniem testów.

Jeśli zainstalowałeś programowanie pulpitu tylko w C ++ , rozwiązaniem jest zainstalowanie programowania Universal Windows Platform z opcjonalnymi narzędziami C ++ Universal Windows Platform . Możesz je wybrać w instalatorze internetowym Visual Studio.

Następnie odbuduj projekt testowy i odnajdywanie testów powinno działać.

Przy okazji, stworzyłem projekt testu jednostkowego w VS2017. Może to być ważne, ponieważ niektórzy użytkownicy wspomnieli, że mieli problemy z wykrywaniem w projektach migrowanych z VS2015 do VS2017.

Usunięcie starej .dll powinno pomóc. Czyszczenie plików tymczasowych znajdujących się w katalogu% TEMP% w C: \ Users (twoja nazwa użytkownika) \ AppData \ Local \ Temp

Miałem ten sam problem. Moje rozwiązanie było OK, ale nagle, gdy otworzyłem rozwiązanie, okazało się, że testy zniknęły.

Wreszcie zdegradowany Microsoft.VisualStudio.TestPlatform.TestFrameworki Microsoft.VisualStudio.TestPlatform.TestFramework.Extensionspakiety do bardzo starej wersji (przy użyciu menedżer Nuget) i metody badań pokazał. Następnie zaktualizowałem do najnowszej wersji i nadal tam były.

Więc po prostu obniż i uaktualnij pakiety.

W moim przypadku żadne z powyższych nie pomaga mi. Ale obniżam wersję NUNit3TestAdapter do wersji 3.8.0, a następnie aktualizuję do najnowszej wersji (3.10.0)

Czasami zmienia się przestrzeń nazw testów. Miałem strukturę folderów w następujący sposób:

A |___B | |___D |___C___E

Przestrzeń nazw była płaska jak Testy. <Nazwa> i nie pojawiły się w oknie testowym. Kiedy zmieniłem przestrzeń nazw na strukturę katalogu, pokazały się wszystkie testy. Teraz mogę wrócić do dowolnej innej struktury przestrzeni nazw, którą chcę.

Nie zapomnij zbudować swojego projektu!

W przypadku .NET Framework w projekcie testowym były wcześniej odniesienia do następujących bibliotek DLL:

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

Usunąłem je i dodałem odniesienie do:

Microsoft.VisualStudio.QualityTools.UnitTestFramework

A potem wszystkie testy pojawiły się i zaczęły działać w taki sam sposób jak poprzednio.

Próbowałem już prawie wszystkich innych powyższych sugestii, ale po prostu ponowne odwołanie się do testowych bibliotek DLL działało dobrze. Opublikowałem tę odpowiedź dla tych, którzy są w moim przypadku.

W moim przypadku miałem do czynienia z tym samym problemem, aby go rozwiązać

1. Otworzyłem konsolę Windows (klawisz Windows + cmd).
2. Przejdź do folderu, w którym projekt został utworzony.
3. Wykonano polecenie „test dotnet”. Jest to zasadniczo ten sam test, który wykonuje studio Visual Studio, ale po uruchomieniu go na konsoli pozwala zobaczyć pełny ślad.
4. Otrzymałem ten komunikat o błędzie „Atrybut TestClass zdefiniowany w niepublicznej klasie MSTest.TestController.BaseTest”
5. Poszedłem więc do przypadku testowego i oznaczyłem go jako publiczny, buduję ponownie, a moje testy są wyświetlane poprawnie

Na początku próbowałem użyć MSTest. Następnie zmieniam go na test Nunit. Potem chciałem poprzeć MSTest. Usunąłem wszystkie kody nUnit i odniesienia, ale Eksplorator testów nie pokazał metod MSTest. Rozwiązanie: usunąłem wszystkie odniesienia do nugetów i ponownie zainstalowałem. Gotowe.

Dla mnie zmiana TargetFramework w .csprojpliku projektu testowego z

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

do

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

pracował

W moim przypadku problemem było ustawienie typu projektu na bibliotekę statyczną (lib) i powinna to być biblioteka dynamiczna (dll)