Pytanie odnosi się konkretnie do „testów białych skrzynek”. To tutaj twoje testy mają dogłębną wiedzę na temat wewnętrznej struktury twojego kodu i potwierdzają zachowanie na każdym kroku, a nie tylko wejście / wyjście / efekt uboczny (testowanie czarnej skrzynki). Chociaż JUnit doskonale nadaje się do obu tych zadań, potrzebujesz dodatkowych dodatkowych ram, aby to zrobić w kontekście testu jednostkowego.
EasyMock i JMock to dobre ramy do tego celu. Mam tendencję do faworyzowania JMocka.
Ryzykując rozpoczęcie debaty OT, powinieneś dokładnie przemyśleć konsekwencje testów białej skrzynki. Testy białych skrzynek są ściśle powiązane z twoim kodem (oczywiście), a jeśli nie są używane ostrożnie, kpiące ramy mogą powodować, że twoje testy są dość skomplikowane, trudne do odczytania i wydają się bardziej kruche podczas refaktoryzacji.
Zwykle trzymam się mieszanki obu. Gdziekolwiek to możliwe, testy czarnej skrzynki i testy białej skrzynki oszczędnie stosowane do bardziej ryzykownego / bardziej skomplikowanego kodu.
Oczywiście powyższe frameworki mogą być również używane w testach czarnej skrzynki, w których liczba klas przyczyniających się (wstrzykiwanych) jest duża, a proste stubowanie staje się nieporadne.
Odnośnie TDD - jest to przede wszystkim poprawa projektu do pisania kodu, a nie po prostu sposób pisania testów. Testy, które przeprowadziłeś na końcu, są ważnym rezultatem, ale ponadto podejście ma na celu ulepszenie projektu i struktury Twojej aplikacji.