Testy w Javie - Jak pisać, by działały, nie pękały?

Automatyzacja testów w Javie ma sens wtedy, gdy skraca czas wykrywania błędów i porządkuje pracę zespołu, a nie tylko zwiększa liczbę plików w repozytorium. Dobrze zaprojektowany zestaw testów łapie regresje na kilku poziomach: od prostych reguł biznesowych po integracje z bazą, API i przeglądarką. Poniżej pokazuję, jak dobrać narzędzia, jak pisać testy, które da się utrzymać, i gdzie najczęściej psuje się cały proces.

Co naprawdę obejmują testy automatyczne w Javie

Ja zwykle zaczynam od pytania: co tu może realnie pójść źle? Jeśli problemem są reguły biznesowe, wystarczą testy jednostkowe. Jeśli ryzyko leży w mapowaniu encji, serializacji JSON albo w transakcji, potrzebny jest poziom integracyjny. Jeśli z kolei klient może wysypać się przez błędny flow w przeglądarce, dopiero wtedy sens ma Selenium lub inna warstwa UI. Nie ma sensu używać ciężkiej armaty do prostych reguł, bo dostajesz wolny i kruchy zestaw, który zniechęca zespół do uruchamiania testów w ogóle.

To prowadzi prosto do pytania, jakim zestawem narzędzi najlepiej to ogarnąć w praktyce.

Z jakiego zestawu narzędzi korzysta się dziś najczęściej

Gdybym miał dziś budować nowy projekt Java od zera, nie kombinowałbym z egzotycznym stackiem. Najczęściej wygrywa prosty zestaw, który dobrze się uzupełnia: JUnit do struktury i uruchamiania testów, Mockito do izolacji zależności, Testcontainers do wiarygodnych integracji oraz Selenium do automatyzacji przeglądarki. W projektach Springowych często dochodzi jeszcze warstwa `spring-boot-starter-test`, która spina te elementy w jeden wygodny punkt startu.

W praktyce największą różnicę robi nie samo narzędzie, tylko to, czy umiesz je dobrać do ryzyka. Jeśli test nie potrzebuje prawdziwej bazy, nie odpalaj bazy. Jeśli potrzebuje prawdziwej bazy, nie udawaj jej mockiem. Z takiego podejścia rodzi się sensowna architektura testów, a nie tylko przypadkowa kolekcja klas z adnotacją `@Test`.

Sam zestaw jednak nie wystarczy; liczy się jeszcze to, jak piszesz pojedynczy test.

Jak pisać testy, które są czytelne i stabilne

Najbardziej użyteczny test to taki, który da się przeczytać bez zgadywania, co autor miał na myśli. Ja trzymam się prostego układu: Arrange - Act - Assert. Najpierw przygotowanie danych i zależności, potem jedno działanie, na końcu jasna asercja. Dzięki temu test nie przypomina sklejki z przypadkowych wywołań, tylko krótki opis zachowania systemu.

import org.junit.jupiter.api.Test;

import static org.junit.jupiter.api.Assertions.assertEquals;
import static org.mockito.Mockito.mock;
import static org.mockito.Mockito.verify;
import static org.mockito.Mockito.when;

class OrderServiceTest {

    @Test
    void calculates_discount_for_regular_customer() {
        PricingPolicy pricingPolicy = mock(PricingPolicy.class);
        OrderService service = new OrderService(pricingPolicy);

        when(pricingPolicy.discountFor("regular")).thenReturn(10);

        int total = service.calculateTotal(100, "regular");

        assertEquals(90, total);
        verify(pricingPolicy).discountFor("regular");
    }
}

Ten przykład pokazuje kilka dobrych nawyków naraz. Test ma jeden cel, używa prostych danych, nie wchodzi w prywatne szczegóły klasy i kończy się asercją, która mówi dokładnie, co ma się wydarzyć. Jeśli w teście musisz przygotować pół aplikacji, to zwykle znak, że testujesz za szeroki fragment albo że logika nie została wystarczająco rozdzielona.

• Nazywaj testy po zachowaniu zamiast po metodzie. Lepiej brzmi „calculates_discount_for_regular_customer” niż „testDiscount”.
• Używaj deterministycznych danych. Losowe wartości, zależność od aktualnej daty i zewnętrzny stan to prosta droga do niestabilności.
• Unikaj `Thread.sleep` jako sposobu na „ustabilizowanie” testu. To maskuje problem, a nie go rozwiązuje.
• Nie testuj prywatnych metod tylko po to, żeby podbić pokrycie. Lepiej przetestować publiczne zachowanie, które z nich wynika.

Jeżeli ten sposób pracy staje się nawykiem, dużo łatwiej później rozłożyć testy na właściwe poziomy. I właśnie o tym warto teraz powiedzieć wprost.

Jak rozkładać testy między poziomy

W dobrze ułożonym projekcie nie wszystko siedzi na jednym poziomie. Ja traktuję piramidę testów jako praktyczną heurystykę, a nie dogmat. Najwięcej miejsca dostaje warstwa jednostkowa, mniej integracyjna, a na górze zostaje tylko to, co naprawdę musi przejść przez cały system. Dla większości aplikacji biznesowych sensownym punktem startu jest około 60-80% testów jednostkowych, 15-30% integracyjnych i 5-10% E2E. To nie jest norma prawna ani branżowy nakaz, ale dobre proporcje do pracy na co dzień.

Jeśli lokalny zestaw testów zaczyna przekraczać kilkadziesiąt sekund przy zwykłym uruchomieniu, zespół zwykle traci odruch odpalania go często. Ja wolę mieć szybki pakiet podstawowy, który kończy się niemal od ręki, i osobno cięższe testy integracyjne albo E2E uruchamiane w pipeline. To pozwala utrzymać rytm pracy bez czekania na wynik dłużej, niż to naprawdę konieczne.

Nawet dobra piramida psuje się jednak, gdy wchodzą w grę złe nawyki. I to jest najkrótsza droga do flakiness.

Najczęstsze błędy, które psują cały zestaw

W wielu repozytoriach problemem nie jest brak testów, tylko ich niska jakość. Najczęściej widzę te same pułapki, niezależnie od branży czy wielkości zespołu.

• Nadmierne mockowanie wszystkiego. Jeśli połowę testu zajmuje ustawianie dublerów, prawdopodobnie testujesz zbyt dużo implementacji, a za mało zachowania.
• Testowanie prywatnych szczegółów. Gdy test zaczyna pękać po refaktoryzacji, która nie zmienia funkcji systemu, to zwykle zły znak.
• Współdzielony stan. Zostawiona baza, globalne singletony albo dane, które „przeciekają” między testami, bardzo szybko powodują losowe porażki.
• Oparcie o czas. `Thread.sleep`, czekanie na „może już się wykonało” i ręczne opóźnienia są objawem problemu z synchronizacją, nie rozwiązaniem.
• Zbyt ciężkie testy UI. Przeglądarka to świetne narzędzie do kilku krytycznych ścieżek, ale fatalna podstawa całej strategii testowej.
• Ignorowanie flaky tests. Jeżeli test bywa czerwony „raz na jakiś czas”, trzeba go naprawić albo wyłączyć z głównej ścieżki, a nie przyzwyczajać zespół do losowości.

Moja praktyczna zasada jest prosta: jeśli test wymaga dużej ilości przygotowań, wielu `when(...)` i kilku warstw fake’ów, to często znak, że kod produkcyjny potrzebuje lepszego rozdzielenia odpowiedzialności. Testy nie powinny być pokrętną łamigłówką. Mają być szybkim sygnałem, że coś działa albo przestało działać.

Z tego miejsca łatwo już przejść do planu wdrożenia w nowym projekcie.

Co wdrożyłbym od razu w nowym projekcie Java

Gdy startuję z nową aplikacją, zaczynam od minimalnego, ale rozsądnego zestawu. Najpierw JUnit Jupiter i Mockito, bo to daje szybki feedback na poziomie logiki. Potem dokładam Testcontainers tam, gdzie naprawdę chcę widzieć realną bazę, brokera lub inny zewnętrzny komponent. Selenium zostawiam na końcu i używam tylko dla kilku przepływów, które faktycznie reprezentują wartość biznesową.

• Oddziel szybkie testy od ciężkich. To, co ma działać po każdym commicie, powinno kończyć się w sekundy, nie w minuty.
• Używaj builderów i fixture’ów. Dzięki nim dane testowe są krótsze, czytelniejsze i mniej kruche.
• Trzymaj integracje blisko realnego środowiska. Jeśli kod mówi z PostgreSQL albo Kafka, warto to sprawdzić naprawdę, a nie na sztucznej imitacji.
• Nie rozbudowuj E2E ponad potrzebę. Kilka dobrych scenariuszy wystarczy, żeby chronić najważniejsze ścieżki.
• Wpinaj testy w CI od początku. Test, którego nikt nie uruchamia automatycznie, szybko staje się dekoracją.

Jeśli miałbym zostawić jedną praktyczną zasadę, byłaby taka: najpierw chroń logikę biznesową szybkim testem jednostkowym, potem potwierdzaj integracje tam, gdzie wchodzi baza, sieć lub przeglądarka. Taki układ daje najlepszy stosunek kosztu do pewności i zwykle skaluje się lepiej niż rozbudowany, ale kruchy zestaw testów końcowych.