Pracuję nad projektem, w którym połączenia wewnętrzne klasy są zwykle, ale wyniki są wielokrotnie proste. Przykład ( nie prawdziwy kod ):
public boolean findError(Set<Thing1> set1, Set<Thing2> set2) {
if (!checkFirstCondition(set1, set2)) {
return false;
}
if (!checkSecondCondition(set1, set2)) {
return false;
}
return true;
}
Pisanie testów jednostkowych dla tego typu kodu jest naprawdę trudne, ponieważ chcę tylko przetestować system warunków, a nie implementację rzeczywistych warunków. (Robię to w osobnych testach.) W rzeczywistości byłoby lepiej, gdybym zdał funkcje, które implementują warunki, a w testach po prostu podałem jakiś próbny. Problemem w tym podejściu jest hałas: często używamy leków generycznych .
Działające rozwiązanie; ma jednak na celu uczynienie testowanego obiektu szpiegiem i wykpienie wywołań funkcji wewnętrznych.
systemUnderTest = Mockito.spy(systemUnderTest);
doReturn(true).when(systemUnderTest).checkFirstCondition(....);
Problem polega na tym, że implementacja SUT została skutecznie zmieniona i utrzymywanie synchronizacji testów z implementacją może być problematyczne. Czy to prawda? Czy istnieje najlepsza praktyka pozwalająca uniknąć spustoszenia wywołań metod wewnętrznych?
Zauważ, że mówimy o częściach algorytmu, więc podział go na kilka klas może nie być pożądaną decyzją.
źródło
Jeśli oba
findError()
icheckFirstCondition()
itp. Są publicznymi metodami twojej klasy, tofindError()
jest to faktycznie fasada dla funkcjonalności, która jest już dostępna z tego samego API. Nie ma w tym nic złego, ale oznacza to, że musisz napisać dla niego testy, które są bardzo podobne do już istniejących testów. Ta duplikacja po prostu odzwierciedla duplikację w interfejsie publicznym. To nie jest powód, by traktować tę metodę inaczej niż inne.źródło
Testy jednostkowe powinny przetestować umowę; to dla nich jedyna ważna rzecz. Testowanie czegokolwiek, co nie jest częścią umowy, to nie tylko strata czasu, ale także potencjalne źródło błędów. Za każdym razem, gdy zobaczysz programistę zmieniającego testy, gdy zmieni szczegóły implementacji, powinny zadzwonić dzwonki alarmowe; ten programista może (celowo lub nie) ukrywać swoje błędy. Celowe testowanie szczegółów implementacji wymusza ten zły nawyk, zwiększając prawdopodobieństwo maskowania błędów.
Połączenia wewnętrzne są szczegółami implementacyjnymi i powinny być jedynie przydatne do pomiaru wydajności . Co zwykle nie jest zadaniem testów jednostkowych.
źródło
a
zawiera wywołanie metodyb
w tej samej klasie, wówczas testya
muszą obejmować testyb
. I nie ma sposobu, aby to zmienić, dopókib
nie zostanie przekazanea
jako parametr. Ale nie ma innego rozwiązania, rozumiem.b
jest częścią interfejsu publicznego, i tak należy go przetestować. Jeśli tak nie jest, nie trzeba go testować. Jeśli podałeś go do publicznej wiadomości tylko dlatego, że chciałeś go przetestować, zrobiłeś źle.Po pierwsze zastanawiam się, co jest trudne do przetestowania w przykładowej funkcji, którą napisałeś? O ile widzę, możesz po prostu przekazać różne dane wejściowe i sprawdzić, czy zwracana jest poprawna wartość logiczna. czego mi brakuje?
Jeśli chodzi o szpiegów, rodzaj tak zwanych testów „białych skrzynek”, w których wykorzystuje się szpiegów i kpiny, jest o rząd wielkości większy do napisania, nie tylko dlatego, że jest o wiele więcej kodu testowego do napisania, ale za każdym razem implementacja jest zmieniony, musisz również zmienić testy (nawet jeśli interfejs pozostaje taki sam). Ten rodzaj testowania jest również mniej niezawodny niż testowanie czarnej skrzynki, ponieważ musisz upewnić się, że cały ten dodatkowy kod testowy jest poprawny, i chociaż możesz ufać, że testy jednostkowe czarnej skrzynki zakończą się niepowodzeniem, jeśli nie będą zgodne z interfejsem , nie można ufać temu w kwestii nadużywania kodu, ponieważ czasami test nawet nie testuje zbyt wiele prawdziwego kodu - tylko symulacje. Jeśli próby są niepoprawne, istnieje prawdopodobieństwo, że testy się powiodą, ale kod nadal jest uszkodzony.
Każdy, kto ma doświadczenie w testowaniu białych skrzynek, może powiedzieć ci, że pisanie i utrzymywanie jest uciążliwe. W połączeniu z faktem, że są mniej niezawodne, testy białych skrzynek są po prostu znacznie gorsze w większości przypadków.
źródło