@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.
Chyba mamy inne rozumienie tego co znaczy "przetestowana" funkcjonalność. Mam wrażenie że masz trochę niżej postawioną poprzeczkę, czegoś co według Ciebie można uznać za przetestowane.
Rozumiem że jeśli zrobić request pod endpoint i dostaniesz jakiś kod oraz response, to to znaczy że to jest przetestowane.
Ja mam trochę inne kryterium.
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.
Ale nadal testowanie aplikacji jest uzależnione od interfejsu HTTP.
Zgadzam się że testowanie aplikacji jest trudne. Musi być spełniony szeroki szereg wymagań, żeby można było powiedzieć że coś jest dobrze przetestowane, rozwiązanie które Ty prezentujesz spełnia tylko kilka z nich. Więc dla mnie nie jest wystarczająco dobre. Jasne, ma kilka zalet, ale wady też masz. Według mnie należałoby poprawić te testy żeby wyeliminować te wady, jednocześnie nie prowadząc do overenigneeringu. To jest trudne, co wyjaśnia czemu większość programmerów tego nie robi, ale jeśli już się umie to zyski są warte wysiłku, zarówno na krótką i długa metę.