Jeżeli już chcesz coś testować, to nie tak jak pisał @Pinek, bo to pisanie kolejnego zestawu testcasów dla Mockito.
Serwisy
Testujesz je jednostkowo, ale tylko gdy zawierają jakąś sensowna logikę. Serwis w postaci:
public void saveUser(User user){
userDao.save(user);
}
Nie zawiera sensownej logiki. Serwis z sensowną, z punktu testów, logiką:
public void saveUser(User user){
if(user.hasMinimumAge() && parentialService.verify(user)){
userDao.save(user);
} else{
logging.cannotSave(user);
}
}
Testujesz też wszelkiej maści złożone logiki. Dodatkowo nie weryfikujesz wywołania mocków, bo zmiana implementacji może za sobą pociągnąć np. zmianę liczby wywołań.
DAO
Jeżeli używasz Spring Data, to wystarczy smoke test, który sprawdza czy wstaje kontekst. Spring się wywali jeżeli nie będzie potrafił sparsować nazw metod w interfejsach. Jeżeli używasz zapytań JPQL, to testujesz je na poziomie integracyjnym. Jeżeli używasz native SQL, to mi nawet nie jest ciebie szkoda ;) Generalnie zapytania można testować w narzędziach dostawców baz danych.
Kontrolery
Po co? Kontrolery w Springu co do zasady nie zawierają testowalnej logiki i są tylko wejściami do systemu.
Testy integracyjne
Tu masz dwie grupy. Pierwsza to smoke testy. Czy wstaje kontekst (testujesz poprawność konfiguracji)? Czy poszczególne usługi odpowiadają, bo konfigurujemy je stringami i trzeba sprawdzić literówki? Czy nagłówki http są sensowne? Druga grupa to właściwe testy integracyjne. Testujesz tu jak współdziałają poszczególne komponenty. Osobiście piszę je „pod flow”, czyli wybieram sobie pojedynczy use case i w ramach testu integracyjnego „przeklikuję” go sprawdzając czy na różnych poziomach mam poprawne stany. Przy czym nie wnikam za bardzo w biznesową sensowność niektórych stanów. Testy integracyjne są też bazą do testów wydajnościowych.
Testy akceptacyjne
Osobna działka, na razie nie powinno cię to jakoś obchodzić.