W Visual Studio 2010 mam kilka testów jednostkowych. Kiedy uruchamiam wiele testów jednocześnie przy użyciu list testów, czasami pojawia się następujący błąd dla jednego lub więcej testów:

Proces agenta został zatrzymany podczas wykonywania testu.

Nigdy nie oznacza to, że ten sam test kończy się niepowodzeniem, a jeśli spróbuję ponownie uruchomić test, kończy się on sukcesem.

Znalazłem ten raport o błędzie w Connect , który wydaje się być tym samym problemem, ale nie oferuje rozwiązania.

Czy ktoś jeszcze widział to zachowanie? Jak mogę tego uniknąć?

Edytować

Nadal mam ten błąd, podobnie jak wielu moich kolegów na tej samej konfiguracji oprogramowania / sprzętu. Oceniłem dotychczas odpowiedzi, ale nie rozwiązują one problemu. Rozpoczynam nagrodę za rozwiązanie tego problemu.

Właśnie doświadczyłem podobnego problemu: niektóre testy kończą się niepowodzeniem i są różne w różnych przebiegach testowych. Nie wiem dokładnie, dlaczego tak się dzieje, ale zaczęło się to dziać, kiedy dodałem finalizator do jednego z moich zajęć. Kiedy wyłączam finalizator - problem znika. Kiedy włączam finalizator - problem wraca.

W tej chwili nie wiem, jak to przezwyciężyć.

Ten komunikat jest spowodowany przez wyjątek w wątku innym niż wątek wykonujący test . Wszystkie dotychczasowe odpowiedzi sprowadzają się do tego prostego wyjaśnienia. Jest to znany błąd programu Visual Studio, który nie wyświetla w takim przypadku żadnych sensownych informacji.

Program uruchamiający testy programu Visual Studio całkowicie się dławi, jeśli wątek inny niż wykonujący wątek testowy zgłosi wyjątek: zostanie połknięty i nie ma wyjścia, nie ma szans na przechwycenie i debugowanie oraz nic poza spalonym, tlącym się bałaganem, który miał być Twoją jednostką test.

Miałem ten problem i okazało się, że jest to problem w moim kodzie, którego Framework Testów nie wychwytuje poprawnie. Mała przypadkowa refaktoryzacja pozostawiła mi ten kod:

public void GetThingy()
{
    this.GetThingy();
}

Jest to oczywiście nieskończona rekurencja i spowodowała wyjątek StackOverflowException (chyba). Powodowało to przerażające: „Proces agenta został zatrzymany podczas wykonywania testu”.

Szybka inspekcja kodu pokazała mi problem, a moje testy działają teraz poprawnie. Mam nadzieję, że to pomoże - może warto sprawdzić kod w poszukiwaniu problemów, a może wyodrębnić trochę do aplikacji konsolowej i sprawdzić, czy tam działa poprawnie.

Udało mi się znaleźć źródło mojego problemu, przeglądając plik wyników testu (/TestResults/*.trx). Zawierał on wszystkie szczegóły wyjątku, który wystąpił w wątku w tle, a kiedy rozwiązałem ten wyjątek, agent przetworzył zatrzymany ... ”błąd zniknął.

W moim przypadku przypadkowo uruchomiłem GUI w moim teście jednostkowym, co ostatecznie spowodowało wyrzucenie wyjątku System.ComponentModel.InvalidAsynchronousStateException.

Więc mój plik .trx zawierał:

   <RunInfo computerName="DT-1202" outcome="Error" timestamp="2013-07-29T13:52:11.2647907-04:00">
    <Text>One of the background threads threw exception: 
System.ComponentModel.InvalidAsynchronousStateException: An error occurred invoking the method.  The destination thread no longer exists.
at System.Windows.Forms.Control.WaitForWaitHandle(WaitHandle waitHandle)
at System.Windows.Forms.Control.MarshaledInvoke(Control caller, Delegate method, Object[] args, Boolean synchronous)
at System.Windows.Forms.Control.Invoke(Delegate method, Object[] args)
at System.Windows.Forms.Control.Invoke(Delegate method)
...
</Text>
  </RunInfo>

Nie dostarczyło to żadnych informacji o tym, który test spowodował błąd, ale pokazało mi, gdzie był wyjątek, co było bardzo przydatne.

Ten komunikat jest zwykle generowany, gdy proces testowy ulega awarii i może się zdarzyć, gdy wystąpi nieobsługiwany wyjątek w wątku w tle, nastąpi przepełnienie stosu lub jawne wywołanie Process.GetCurrentProcess().Kill()lub Environment.Exit. Inną możliwą przyczyną jest naruszenie dostępu w niezarządzanym kodzie.

Coś, o czym nikt nie wspomniał, to fakt, że w dzienniku zdarzeń mogą znajdować się dodatkowe informacje. Zwykle nie dostaniesz zbyt wielu informacji o tym, dlaczego test zakończył się awarią w wynikach, jednak w przypadku nieobsłużonego wyjątku w wątku w tle, struktura testowa zapisuje szczegóły do ​​dziennika zdarzeń aplikacji ze źródłem VSTTExecution. Jeśli w dzienniku zdarzeń nie ma żadnych informacji, prawdopodobnie jest to jedna z innych przyczyn wymienionych powyżej.

W moim przypadku rozwiązanie zostało rozwiązane przez sprawdzenie okna wyjściowego .

„QTAgent32.exe” (Managed (v4.0.30319)): załadowano „C: \ TestResults \ bdewey_XXXXXX072 2011-01-11 17_00_40 \ Out \ MyCode.dll”, załadowano symbole. E, 9024, 9, 2011/01/11, 17: 00: 46.827, XXXXX072 \ QTAgent32.exe, Unhandled Exception Caught, raportowanie przez Watson: [Komunikat o wyjątku]

W moim przypadku miałem FileSystemWatcher, który generował błąd w osobnym wątku.

Napotkałem ten sam problem i rozwiązałem go podczas usuwania

Environment.Exit(0);

Jestem więc prawie pewien, że ten błąd występuje, gdy test lub testowana metoda powoduje zakończenie procesu wykonywania.

Dzięki za zadanie pytania. Właśnie natknąłem się na ten problem i znalazłem przyczynę, na którą możesz się natknąć.

Mógł wystąpić asynchroniczny wyjątek

Podczas konfiguracji testowej tworzę obiekt, który kolejkuje wątek roboczy w puli wątków. Jeśli przeprowadzę debugowanie wystarczająco szybko, mój kod przechodzi.

Jeśli wątek roboczy uruchamia się i pojawia się błąd PRZED zakończeniem konfiguracji testu, otrzymuję wynik Przerwano bez podania przyczyny.

Jeśli wątek roboczy uruchamia się i pojawia się błąd PO rozpoczęciu testu, otrzymuję wynik: Błąd - Proces agenta został zatrzymany podczas wykonywania testu.

Ważna uwaga: jest to komponent, którego używam w kilku moich testach. Jeśli środowisko testowe napotka zbyt wiele z tych błędów, przerywa pozostałe testy.

Mam nadzieję że to pomoże

Dodałem bloki try / catch do descructora ~ ClassName () {}, które zostały zdefiniowane w dowolnej klasie biorącej udział w moich testach. To rozwiązało problem.

~MyClass()
{
    try
    {
        // Some Code
    }
    catch (Exception e)
    {
        // Log the exception so it's not totally hidden
        // Console.WriteLine(e.ToString());
    }
}

Aby dowiedzieć się, gdzie został zgłoszony wyjątek, kliknij hiperłącze „Błąd uruchomienia testowego” obok ikony wykrzyknika w oknie Wyniki testu. Otworzy się okno ze śladem stosu.

To bardzo pomaga w wyśledzeniu błędu!

Miałem ten sam problem i był on spowodowany przez finalizator niezarządzanego zasobu (program zapisujący plik, który z jakiegoś powodu nie został prawidłowo usunięty).

Po zawinięciu kodu finalizatora w próbny chwyt, który połyka wyjątek, problem zniknął. Nie polecam połykania takich wyjątków, więc oczywiście mądrze byłoby dowiedzieć się, dlaczego wyjątek występuje w pierwszej kolejności.

Zdarzało mi się to przy dziwnych okazjach, a winowajca prawie zawsze się nawija.

O dziwo, wszystkie testy działałyby dobrze na maszynach programistycznych, a następnie losowo kończyły się niepowodzeniem na serwerach kompilacji.

Po bliższym przyjrzeniu się okazało się, że chociaż testy były wymieniane jako zaliczone na dev boxach, były wyjątki. Wyjątki były umieszczane w osobnym wątku, który nie został odebrany jako błąd.

Szczegóły wyjątku były rejestrowane w śladzie testu, więc byliśmy w stanie zidentyfikować, który kod / testy wymagają modyfikacji.

Mam nadzieję, że to komuś pomoże.

W moim przypadku miałem kilka testów jednostkowych dla usługi WCF. Ta usługa WCF uruchamiała 2 liczniki czasu.
Te timery spowodowały efekty uboczne.
-> Domyślnie wyłączam te timery i wszystko jest w porządku!

BTW: Używam WCFMock do fałszowania usługi WCF, więc mam „prawdziwe” testy jednostkowe wokół mojej usługi WCF

Ten błąd został również spowodowany przez Finalizer dla mnie.
Finalizer aktywnie wywoływał kod bazy danych, który nie został wyszydzony. Znalezienie go zajęło mi trochę czasu, ponieważ nie była to klasa, którą napisałem, a odniesienie do niego było pogłębione o kilka klas.

Napotkałem podobny problem, gdy test kończy się niepowodzeniem w TestInitialize, a także uruchamia kod z ddl z innego z moich projektów. Otrzymuję komunikat o błędzie opisany powyżej i jeśli spróbuję zdebugować test, test jest po prostu przerywany bez żadnych szczegółów wyjątku.

Podejrzewam, że problem może polegać na tym, że biblioteki DLL z mojego innego projektu pochodzą z projektu Visual Studio 2012 i przeprowadzam testy w projekcie VS2010 i / lub prawdopodobnie wersje dll UnitTestFramwork z 2 projektów są niezgodne.

Problem może również zostać wywołany przez wyjątek lub Stackoverflow w konstruktorze klasy TestClass.

Ponieważ ten błąd może mieć wiele różnych przyczyn, chciałbym dodać kolejną dla kompletności tego wątku.

Jeśli wszystkie testy są przerywane zgodnie z opisem w OP, przyczyną może być nieprawidłowa konfiguracja projektu. W moim przypadku docelowy framework został ustawiony na .NET Framework 3.5. Ustawienie go na wyższą wersję za pośrednictwem strony właściwości projektu (zakładka Aplikacja ) rozwiązało problem.

Udało mi się ustalić, co jest przyczyną mojego problemu, przeglądając Dzienniki systemu Windows > wpisy dziennika aplikacji w Podglądzie zdarzeń systemu Windows . Poszukaj wpisów w czasie, gdy test został zbombardowany. Miałem Error wpis podobny do poniżej:

QTAgent32_40.exe, PID 10432, Thread 2) AgentProcess:CurrentDomain_UnhandledException: IsTerminating : System.NullReferenceException: Object reference not set to an instance of an object.
   at XXX.YYY.ZZZ.cs:line 660
   at XXX.YYY.AAA.Finalize() in C:\JenkinsSlave\workspace\XXX.YYY.AAA.cs:line 180

To rzeczywiście był zerowy wyjątek odwołania w metodzie wywołanej z finalizatora klasy.

Oto wskazówka dla każdego, kto zadaje sobie to stare pytanie i zastanawia się, co jest wyrzucane z ich wątków. Korzystanie z Task.Run (w przeciwieństwie do, powiedzmy, Thread.Start) zgłosi wyjątki wątków potomnych znacznie bardziej niezawodnie. Krótko mówiąc, zamiast tego:

Thread t = new Thread(FunctionThatThrows);
t.Start();
t.Join();

Zrób to:

Task t = Task.Run(() => FunctionThatThrows());
t.Wait();

Twoje dzienniki błędów powinny być znacznie bardziej przydatne.