Czy szpiegowanie sprawdzonych klas to zła praktyka?

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

Testy jednostkowe powinny traktować badane klasy jako czarne skrzynki. Liczy się tylko to, że jej publiczne metody zachowują się tak, jak się spodziewano. Sposób, w jaki klasa to osiąga za pomocą wewnętrznych metod państwowych i prywatnych, nie ma znaczenia.

Kiedy czujesz, że nie można w ten sposób tworzyć znaczących testów, jest to znak, że twoje klasy są zbyt potężne i robią za dużo. Powinieneś rozważyć przeniesienie części ich funkcjonalności do osobnych klas, które można testować osobno.

Jeśli oba findError()i checkFirstCondition()itp. Są publicznymi metodami twojej klasy, to findError()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.

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.

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.