@somekind: Nie wiem czy to co mam na myśli, to testy integracyjne, jednostkowe, e2e czy może da się im nakleić jeszcze jakąś inną etykietkę. Wszystko co próbowałem nieudolnie napisać, to że testy powinny być tworzone maksymalnie wysoko i bez wnikania w sposób implementacji. Jeżeli mam np. mikroserwis, zajmujący się obsługą CRUD jakiegoś obiektu biznesowego, to da się jego funkcjonalność przetestować "black box", czyli z poziomu API, bo wywołanie POST, PUT, DELETE zmienia wynik zwracany przez GET. W takim razie, z tego poziomu powinno dać się przetestować całą funkcjonalność aplikacji.
Problemem jest to, że czasami nie da się tego zaimplementować, bo np. po drodze podnosi się jakiś wielgachny serwer aplikacyjny i trwa to najzwyczajniej w świecie za długo, albo rolą tej usługi jest nie tylko zmiana danych na warstwie persistent, ale również wysyłanie informacji o dokonanych zmianach do jakiejś kolejki. To wrzucenie do kolejki będzie pokryte z automatu, ale nie będzie przetestowanie, bo nie ma tam asercji. Pewnie nie chcemy tego robić na żywym systemie, albo nawet na jakimś środowisku, bo jeżeli 2 programistów w tym samym czasie puści testy, to ich wynik będzie przypadkowy. Więc zasadne stanie się użycie jakiegoś mocka. Tym mockiem może być albo lokalnie odpalona kolejka, albo jakiś mock drivera kolejki, na którym sprawdzimy, czy faktycznie zostało wywołane to co miało zostać wywołane. Wstawienie tego mock'a jest kompromisem pomiędzy tym co chcemy zrobić i jakimiś dodatkowymi ograniczeniami, typu działa za wolno, albo nie chcemy wysyłać tego przelewu naprawdę.
Jeżeli testujemy prostego CRUD'a, to testy ma poziomie REST API pozwalają przetestować całą funkcjonalność, bez nadmiernych kosztów, a jednocześnie to co jest za tym API, nie jest w żaden sposób zabetonowane testami. Możesz sobie nawet podmienić tę Javę na Pythona i testy nadal będą przechodzić, pomijając ewentualne trudności z ich odpaleniem. Jeżeli napiszę testy do kontrolera, to z jednej strony jakiś kawałek logiki aplikacji nie zostanie pokryty testami (mapowanie na endpointy, konfiguracja parsera JSON itp.), z drugiej strony zabetonuję np. nazwy metod tego kontrolera, czyli patrząc tylko na testy - jest gorzej. Nie twierdzę, że nie wolno tak robić, albo, że tak jest źle, ale płacimy jakością testów i muszę sobie zadać pytanie co za to kupuję i czy ta cena nie jest zbyt wysoka.