Testy jednostkowe na żywo — często zadawane pytania

Funkcja Live Unit Testing współpracuje z trzema popularnymi strukturami testowania jednostkowego wymienionymi w poniższej tabeli. Minimalna obsługiwana wersja ich adapterów i struktur znajduje się również w tabeli. Wszystkie struktury testowania jednostkowego są dostępne w NuGet.org.

Jeśli masz starsze projekty testowe oparte na narzędziu MSTest odwołujące się do Microsoft.VisualStudio.QualityTools.UnitTestFramework i nie chcesz przechodzić do nowszych pakietów NUGet MSTest, przeprowadź uaktualnienie do programu Visual Studio 2019 lub Visual Studio 2017.

Tak. Testy jednostkowe na żywo współdziałają z platformą .NET Core i programem .NET Framework.

Okno Dane wyjściowe (po wybraniu listy rozwijanej Live Unit Testing) powinno poinformować, dlaczego testowanie jednostkowe na żywo nie działa. Testy jednostkowe na żywo mogą nie działać z jednego z następujących powodów:

• Jeśli pakiety NuGet, do których odwołują się projekty w rozwiązaniu, nie zostały przywrócone, testy jednostkowe na żywo nie będą działać. Wykonanie jawnej kompilacji rozwiązania lub przywrócenie pakietów NuGet w rozwiązaniu przed włączeniem funkcji Live Unit Testing powinno rozwiązać ten problem.

• Jeśli używasz testów msTest w projektach, upewnij się, że usunięto odwołanie do Microsoft.VisualStudio.QualityTools.UnitTestFrameworki dodano odwołania do najnowszych pakietów NuGet MSTest, MSTest.TestAdapter (wymagana jest minimalna wersja 1.1.11) i MSTest.TestFramework (wymagana jest minimalna wersja 1.1.11). Aby uzyskać więcej informacji, zobacz sekcję "Obsługiwane struktury testowe" w artykule Use Live Unit Testing in Visual Studio (Używanie testowania jednostkowego na żywo w programie Visual Studio).

• Co najmniej jeden projekt w rozwiązaniu powinien mieć odwołanie NuGet lub bezpośrednie odwołanie do platformy testowej xUnit, NUnit lub MSTest. Ten projekt powinien również odwoływać się do odpowiedniego pakietu NuGet kart testowych programu Visual Studio.

Błędy kompilacji są zgłaszane w oknie Dane wyjściowe po wybraniu listy rozwijanej Live Unit Testing. Istnieje kilka typowych problemów spowodowanych nieprawidłową konfiguracją w kreatorze konfiguracji , które mogą powodować problemy z kompilacją w testach jednostkowych na żywo.

• Jeśli właściwość głównego obszaru roboczego jest zbyt długa, możliwe, że kompilacja zakończy się niepowodzeniem z powodu wyjątków wskazujących, że ścieżka jest zbyt długa.

• Jeśli właściwość Repository Root nie wskazuje na katalog główny repozytorium, obszar roboczy zostanie wypełniony niewłaściwym zestawem plików.

• W przypadku repozytoriów git właściwość Exclude files zwykle unika kopiowania plików określonych w pliku gitignore. Można jednak zaewidencjonować pliki w repozytorium Git, które jest ignorowane, lub można uruchamiać narzędzia, które automatycznie generują pliki, ale nie są generowane podczas kompilacji. W takich przypadkach należy wybrać opcję "<Niestandardowy>" i niestandardowy zestaw reguł, które wyświetlają listę tylko folderów artefaktów.

Oprócz opisanych wcześniej problemów następujące konfiguracje projektu, które mogą nie zostać poprawnie skompilowane.

• Jeśli zależności projektu są określane jako globalna konfiguracja rozwiązania, a nie jako ProjectReferences dla każdego projektu, testy jednostkowe na żywo mogą kończyć się tworzeniem niepoprawnego zestawu projektów. Aby rozwiązać ten problem, dodaj jawne odwołania między projektami.

• Dopóki nie zostanie wybrana lista odtwarzania Live Unit Testing, testy jednostkowe na żywo nie będą kompilować żadnych projektów. Aby rozwiązać ten problem, uwzględnij niektóre testy na liście odtwarzania Live Unit Testing.

• Jeśli używasz testów msTest w projektach, upewnij się, że usunięto odwołanie do Microsoft.VisualStudio.QualityTools.UnitTestFrameworki dodano odwołania do najnowszych pakietów NuGet MSTest, MSTest.TestAdapter (wymagana jest minimalna wersja 1.1.11) i MSTest.TestFramework (wymagana jest minimalna wersja 1.1.11). Aby uzyskać więcej informacji, zobacz Obsługiwane platformy testowe.

• Co najmniej jeden projekt w rozwiązaniu powinien mieć odwołanie NuGet lub bezpośrednie odwołanie do platformy testowej xUnit, NUnit lub MSTest. Ten projekt powinien również odwoływać się do odpowiedniego pakietu NuGet kart testowych programu Visual Studio. Adapter testowy programu Visual Studio można również odwoływać się za pomocą pliku .runsettings. Plik .runsettings musi mieć wpis podobny do następującego przykładu:

<RunSettings>
    <RunConfiguration>
          <TestAdaptersPaths>path-to-your-test-adapter</TestAdaptersPaths>
    </RunConfiguration>
</RunSettings>

Testy jednostkowe na żywo nie mogą kompilować projektów generatora źródłowego za pomocą instrumentacji. Ze względu na to, jak kompilator języka C# konfiguruje ładowanie zestawów dla generatorów źródłowych, próba skompilowania projektów generatora źródła z instrumentacją nie może załadować zestawów testów jednostkowych na żywo.

Możesz ustawić właściwość <ExcludeFromCodeCoverage>true</ExcludeFromCodeCoverage> w plikach csproj generatora źródłowego, aby utworzyć te projekty w funkcji Live Unit Testing.

Testy jednostkowe na żywo uruchamiają kompilację wewnątrz własnego procesu ze względu na wydajność. Jeśli ten oddzielny proces kompilacji powoduje błąd, możesz ustawić <UseInProcMSBuildNode>false</UseInProcMSBuildNode> na plik .lutconfig, aby upewnić się, że wszystkie kompilacje będą wykonywane w procesie MSBuild.

• Typowym problemem jest to, że nie wszystkie pliki są kopiowane do folderu testowego. Może być konieczne dodanie niektórych elementów zależności testów jednostkowych na żywo do plików csproj.

• Innym problemem są przekroczenia limitu czasu. Ponieważ funkcja Live Unit Testing uruchamia testy na czas nieokreślony, automatycznie przerywa przebieg, jeśli testy są uruchamiane zbyt długo. Możesz zwiększyć limit czasu w Kreatorze projektu.

• Jeśli wiele projektów w rozwiązaniu odwołuje się do pakietu adaptera testowego NuGet, każdy z nich musi zostać uaktualniony do obsługiwanej wersji.

• Upewnij się, że plik msBuild .props zaimportowany z pakietu adaptera testowego również został poprawnie zaktualizowany. Sprawdź wersję/ścieżkę pakietu NuGet importu, którą zwykle można znaleźć w górnej części pliku projektu, tak jak poniżej:

    <Import Project="..\packages\xunit.runner.visualstudio.2.2.0\build\net20\xunit.runner.visualstudio.props" Condition="Exists('..\packages\xunit.runner.visualstudio.2.2.0\build\net20\xunit.runner.visualstudio.props')" />
  

Jeśli twoje rozwiązanie wymaga niestandardowych kroków do skompilowania instrumentacji (Live Unit Testing), które nie są wymagane w przypadku "regularnej" kompilacji niestrudowanej, możesz dodać kod do projektu lub .targets plików, które sprawdzają właściwość BuildingForLiveUnitTesting i wykonują niestandardowe kroki kompilacji wstępnej/po kompilacji. Możesz również usunąć pewne kroki kompilacji (takie jak publikowanie lub generowanie pakietów) lub dodać kroki kompilacji (takie jak kopiowanie wymagań wstępnych) do kompilacji Live Unit Testing na podstawie tej właściwości projektu. Dostosowywanie kompilacji na podstawie tej właściwości nie zmienia regularnej kompilacji w żaden sposób i ma wpływ tylko na kompilacje testów jednostkowych na żywo.

Na przykład może istnieć element docelowy, który generuje pakiety NuGet podczas regularnej kompilacji. Prawdopodobnie nie chcesz, aby pakiety NuGet są generowane po każdej dokonaniu edycji. Możesz więc wyłączyć ten element docelowy w kompilacji Live Unit Testing, wykonując czynności podobne do następujących:

<Target Name="GenerateNuGetPackages" BeforeTargets="AfterBuild" Condition="'$(BuildingForLiveUnitTesting)' != 'true'">
    <Exec Command='"$(MSBuildThisFileDirectory)..\tools\GenPac" '/>
</Target>

Istnieje kilka różnic:

• Uruchamianie lub debugowanie testów z okna Eksploratora testów uruchamia regularne pliki binarne, podczas gdy testy jednostkowe na żywo uruchamiają instrumentowane pliki binarne. Jeśli chcesz debugować instrumentowane pliki binarne, dodanie wywołania metody Debugger.Launch w metodzie testowej powoduje uruchomienie debugera za każdym razem, gdy ta metoda jest wykonywana (w tym podczas wykonywania przez funkcję Live Unit Testing), a następnie możesz dołączyć i debugować instrumentowany plik binarny. Mamy jednak nadzieję, że instrumentacja jest niewidoczna dla większości scenariuszy użytkownika i że nie trzeba debugować instrumentowanych plików binarnych.

• Testy jednostkowe na żywo nie tworzą nowej domeny aplikacji do uruchamiania testów, ale testy są uruchamiane w oknie eksploratora testów utworzyć nową domenę aplikacji.

• Testy jednostkowe na żywo uruchamiają testy w każdym zestawie testowym sekwencyjnie. W Eksploratora testówmożna uruchomić wiele testów równolegle.

• Eksplorator testów domyślnie uruchamia testy w jednym wątkowym mieszkaniu (STA), podczas gdy testy jednostkowe na żywo uruchamiają testy w wielowątkowy mieszkaniu (MTA). Aby uruchomić testy MSTest w sta w funkcji Live Unit Testing, dekoruj metodę testową lub zawierającą klasę za pomocą atrybutu <STATestMethod> lub <STATestClass>, który można znaleźć w pakiecie MSTest.STAExtensions 1.0.3-beta NuGet. W przypadku elementu NUnit dekoruj metodę testową za pomocą atrybutu <RequiresThread(ApartmentState.STA)> i dla klasy xUnit za pomocą atrybutu <STAFact>.

Zobacz sekcję "Dołączanie i wykluczanie projektów testowych i metod testowych" w artykule Use Live Unit Testing in Visual Studio (Używanie testów jednostkowych na żywo w programie Visual Studio) dla ustawienia specyficznego dla użytkownika. Dołączanie lub wykluczanie testów jest przydatne, gdy chcesz uruchomić określony zestaw testów dla określonej sesji edycji lub zachować własne preferencje osobiste.

W przypadku ustawień specyficznych dla rozwiązania można zastosować atrybut System.Diagnostics.CodeAnalysis.ExcludeFromCodeCoverageAttribute programowo, aby wykluczyć metody, właściwości, klasy lub struktury z instrumentowania przez testy jednostkowe na żywo. Ponadto można również ustawić właściwość <ExcludeFromCodeCoverage> na true w pliku projektu, aby wykluczyć cały projekt z instrumentowania. Testy jednostkowe na żywo będą nadal uruchamiać testy, które nie zostały instrumentowane, ale ich pokrycie nie zostanie zwizualizowane.

Możesz również sprawdzić, czy Microsoft.CodeAnalysis.LiveUnitTesting.Runtime jest ładowana w bieżącej domenie aplikacji, i wyłączyć testy w zależności od przyczyny. Możesz na przykład wykonać następujące czynności za pomocą narzędzia xUnit:

[ExcludeFromCodeCoverage]
public class SkipLiveFactAttribute : FactAttribute
{
   private static bool s_lutRuntimeLoaded = AppDomain.CurrentDomain.GetAssemblies().Any(a => a.GetName().Name ==
                                            "Microsoft.CodeAnalysis.LiveUnitTesting.Runtime");
   public override string Skip => s_lutRuntimeLoaded ? "Test excluded from Live Unit Testing" : "";
}

public class Class1
{
   [SkipLiveFact]
   public void F()
   {
      Assert.True(true);
   }
}

Rozwiązanie może kompilować się nawet wtedy, gdy nie wprowadzasz zmian, jeśli proces kompilacji generuje kod źródłowy, który jest częścią samego rozwiązania, a pliki docelowe kompilacji nie mają określonych odpowiednich danych wejściowych i wyjściowych. Obiekty docelowe powinny mieć listę danych wejściowych i wyjściowych, aby program MSBuild mógł wykonać odpowiednie up-to-date sprawdza i określa, czy jest wymagana nowa kompilacja.

Funkcja Live Unit Testing uruchamia kompilację za każdym razem, gdy wykryje, że pliki źródłowe uległy zmianie. Ponieważ kompilacja rozwiązania generuje pliki źródłowe, funkcja Live Unit Testing przechodzi do nieskończonej pętli kompilacji. Jeśli jednak dane wejściowe i wyjściowe obiektu docelowego są sprawdzane, gdy funkcja Live Unit Testing uruchamia drugą kompilację (po wykryciu nowo wygenerowanych plików źródłowych z poprzedniej kompilacji), wyrywa się z pętli kompilacji, ponieważ sprawdzanie danych wejściowych i wyjściowych wskazuje, że wszystko jest up-to-date.

Ikony w edytorze mogą nie być widoczne, jeśli zestawy, na których działa funkcja Live Unit Testing, nie są instrumentowane z jakiegokolwiek powodu. Na przykład funkcja Live Unit Testing nie jest zgodna z projektami ustawionymi <UseHostCompilerIfAvailable>false</UseHostCompilerIfAvailable>. W takim przypadku proces kompilacji musi zostać zaktualizowany, aby usunąć to ustawienie lub zmienić je na true, aby testy jednostkowe na żywo działały. 

Możesz wykonać kilka czynności, aby zebrać bardziej szczegółowe dzienniki:

• Przejdź do pozycji Tools>Options>Live Unit Testing i zmień opcję rejestrowania na Pełne. Pełne rejestrowanie powoduje wyświetlanie bardziej szczegółowych dzienników w oknie danych wyjściowych.

• Ustaw zmienną środowiskową użytkownika LiveUnitTesting_BuildLog na nazwę pliku, którego chcesz użyć do przechwycenia dziennika MSBuild. Szczegółowe komunikaty dziennika programu MSBuild z kompilacji Live Unit Testing można następnie pobrać z tego pliku.

• Ustaw zmienną środowiskową użytkownika LiveUnitTesting_TestPlatformLog na 1, aby przechwycić dziennik platformy testowej. Szczegółowe komunikaty dziennika platformy testowej z przebiegów testów jednostkowych na żywo można pobrać z [Solution Root]\.vs\[Solution Name]\log\[VisualStudio Process ID].

• Utwórz zmienną środowiskową na poziomie użytkownika o nazwie VS_UTE_DIAGNOSTICS i ustaw ją na 1 (lub dowolną wartość) i uruchom ponownie program Visual Studio. Teraz na karcie dane wyjściowe — testy w programie Visual Studio powinny być widoczne wiele logowania.

Nie, nie należy otwierać ani edytować plików w katalogach kompilacji i testowania folderu obszaru roboczego. Testy jednostkowe na żywo powinny zarządzać wszystkimi plikami w folderze src, aby zachować synchronizację między katalogiem głównym repozytorium i głównym obszarem roboczym .

Tak, ale upewnij się, że jest włączona. Jeśli używasz dysku deweloperskiego, upewnij się, że przewidywany system plików (ProjFS) filtr jest włączony. Na przykład następujące polecenie włącza program ProjFS i usługę Windows Defender:

fsutil devdrv setfiltersallowed PrjFlt,WdFilter

Zobacz też

• Live Unit Testing