JAVA Developer

Nie służą do wyszukiwania błędów funkcjonalnych – koncentrują się one na fragmencie funkcjonalności, nie testują integracji komponentów. Pozwalają na poprawny refactoring oraz rozwój kodu (dokumentują zachowanie komponentów, pozwalają na ocenę poprawności projektu pojedynczego komponentu). Są przeciwieństwem do testów integracyjnych, gdzie testujemy całą funkcjonalność, często bez wiedzy na temat wewnętrznych rozwiązań projektowych.

Dobre praktyki:

• każdy test powinien być niezależnych względem innych (konkretne zachowanie komponentu (zachowanie, a nie metoda publiczna) powinno być testowane tylko raz – w przeciwnym przypadku zmiana zachowania komponentu wymaga poprawy wielu różnych testów).

• testy powinny dotyczyć tylko metod publicznych (kontraktów), więc wyjściem do pisania testów powinny być dobrze zdefiniowane interfejsy.

• najpierw black box, później white box (implementacja testu w oparciu o opis funkcjonalny – często opis w interfejsie, później przegląd implementacji i dodatkowe testy)

• zbyt duża liczba assercji to problem! Jeśli testujemy funkcjonalność biznesową odpowiedzialną za np. zamykanie paczki z transakcjami to nie powinniśmy sprawdzać jednocześnie wszystkich własności paczki (tylko jej status).

• wywołania komponentów zależnych powinny być mockowane (poza warstwą DAO) – np. EasyMock – pozwala to na dużo łatwą ocenę miejsca wystąpienia błędu

• nazewnictwo:

• nazwa klasy (nie interfejsu) + Test

• metody: testowana metoda + scenariusz + wynik (np. removeApplicationIfActiveStateActiveStateException)

• testując komponenty biznesowe nie powinniśmy mockować obiektów DAO

• każdy test sam ustanawia dla siebie środowisko i po jego wykonaniu wszystkie zmiany na bazie testowej powinny być rollbackowane