W drugim teście getActivity() nigdy nie zwraca

Question

Mam kilka prostych testów, takich jak assertNotNull(mActivity); (czytam M.D.Torres "Przewodnik po aplikacjach Android"). Testowane działanie działa poprawnie. Każdy pojedynczy test działa również w porządku. Ale jeśli wykonam kilka testów naraz, drugi test nigdy nie zostanie zwrócony. Brak błędów w logcat (ostatnia linia "Starting Intent ..."), nic nie ma. Debugowanie też nie pomaga, jeśli wkroczę na numer getActivity(), narzeka, że ​​nie ma kodu źródłowego.
Kolejny testowy projekt - ActivityTest z Google działa dobrze nawet po kilku testach, więc Eclipse jest skonfigurowany poprawnie.
Czy ktoś kiedykolwiek napotkał coś takiego?

Answer 1

Ponownie odtworzyłem projekt testowy (np. "Clean room") i zadziałało. Następnie porównałem dwa projekty i znalazłem winnego. To był pusty rozbiór:

protected void tearDown() throws Exception { 
} 

Po usunięciu wszystkie testy przebiegają na zielono. Jeśli go wkleję, drugi test się zawiesza. Teraz chciałbym przeczytać wyjaśnienie i być gotowym do oznaczenia go jako odpowiedzi.

Edit: Byłbym nazywając super.tearDown() na końcu metody tearDown. Przepraszam, że przeszkadzam wszystkim.

Answer 2

Użyłem ActivityInstrumentationTestCase2 do przetestowania działania za pomocą ExoPlayera i prawidłowego oczyszczenia zasobów. Ponieważ oczyszczanie i końcowe sprawdzenia są takie same dla wszystkich testów, pomyślałem, że tearDown() jest dobrym miejscem do ich wdrożenia. Wszystkie testy są uruchamiane osobno, bez żadnego problemu, ale po uruchomieniu wielu testów czasami funkcja getActivity() nie powróciła. Moja łza() realizowane różne rzeczy: stan

• wyboru aktywności (różne assert() połączenia)
• państwowe kontrola odtwarzacza (różne assert() wywołuje)
• oczyścić zasobów odtwarzacza ręcznie (wywołanie blisko() i release())
• setActivity (null) (ten spowodował kłopoty)
• super.tearDown()

próbowałem wszystkich sugerowanych obejścia jak nadpisywanie funkcji getActivity() i używanie innych metod oprzyrządowania do tworzenia i oczyszczania działania. Te metody nie pomogły.

Wiele debugowania pokazało, że w powyższym scenariuszu funkcja onDestory() działania poprzedniego testu może pokrywać się z onCreate() działania następnego testu. Więc dzienniki pokazały wydarzenia w cyklu życia w tej kolejności:

test1.getActivity(); 
test1.tearDown() called; 
test1.tearDown() over; 
test2.getActivity() 
test2.onCreate(); 
test1.onStop(); --> why is this late? 
test1.onDestroy(); --> why is this late? 
test2.tearDown() called; 
test2.tearDown() over; 
test3.getActiviy() --> this should call test3.onCreate, but did not and never returned. 

Ten Dzieje się tak nawet wtedy, gdy przypadki testowe są realizowane w oddzielnych ActivityInstrumentationTestCase2 Zajęcia/plików. I po raz pierwszy to nakładanie się nie sprawia jeszcze kłopotów, więc 2 testy są zawsze w porządku, ale wykonanie 3 testów w dowolnej kolejności powodującej to nakładanie się powoduje, że trzecie wywołanie getActivity() nigdy nie powróci.

Próbowałem wszystkiego jak wywołanie onPause() + onStop() + onDestroy() ręcznie za pomocą oprzyrządowania, wprowadzając naprawdę długie okresy snu między testami, wymuszając wyczyszczenie działania instrumentationTestCase, zmieniając kolejność sprawdzania mojej tearDown, ale nic nie pomogło .Wreszcie, ja przypadkowo usunięte setActivity (null) przed moim kontroli, a wydarzenia cyklu życia został prawidłowo uporządkowane:

test1.tearDown() called; 
test1.onStop(); 
test1.onDestroy(); 
test1.tearDown() over; 
test2.getActivity() 
test2.onCreate(); 
... 

Więc co tak naprawdę robią różnicę w moim przypadku: nie nazywaj ActivityTestCase.setActivity(). Powoduje to, że funkcja super.tearDown() nie wywołuje bezpośrednio zdarzeń cyklu życia w działaniu, czyszczenie nastąpi później i spowoduje problemy.