Projekt naszego kursu

1. Jeden projekt — to rozsądne 🤙

Rozproszone przykłady szkoleniowe są dobre, dopóki temat jest mały i lokalny. Ale testowanie ma inną naturę. Prawie zawsze porównuje kilka poziomów pewności wokół tego samego zachowania. Jeśli dziś patrzysz na jakiś UserController, jutro — na przypadkowy OrderService, a pojutrze — na nowy miniprojekt z plikami, mózg traci siły nie na strategię jakości, ale na ciągłe zapoznawanie się z nową domeną.

Projekt ContentHub zdejmuje tę zbędną nagrodę. Masz przez cały czas przed oczami te same encje: artykuł, status, autor, strefy public/editor/admin, moderacja, załączniki, publikacja. Dzięki temu można uczciwie porównywać różne rozwiązania testowe na identycznym materiale.

To samo ryzyko widoczności artykułu zobaczysz najpierw jako lokalną regułę, potem jako kontrakt JSON, potem jako granicę web, potem jako warstwę danych, potem jako część pełnego integration-flow. Właśnie to daje ważne poczucie spójności: przed tobą nie zestaw technik, ale jeden rosnący obiekt obserwacji 🌱

2. Kod bliski produkcji jest potrzebny nie „dla uproszczenia", ale dla skupienia

Kolejna ważna decyzja kursu — główny kod projektu jest w dużej mierze przygotowany z góry. To może na początku zaskakiwać. Wydaje się, że ciekawiej byłoby pisać cały backend od zera i równolegle testować. W praktyce dla odbiorców na poziomie Junior oznacza to prawie zawsze jedno: skupienie odpływa z strategii testowania na niekończące się dopisywanie kodu produkcyjnego.

Tutaj wybrano inną ścieżkę. ContentHub jest wystarczająco żywy i wystarczająco zwykły: controller, service, repository, DTO, ograniczenia security, zewnętrzne granice, warstwa danych i pełnoprawne scenariusze biznesowe. Tego wystarczy, żeby testowanie było uczciwe i treściwe. Ale nie musisz za każdym razem tracić energii na wymyślanie kolejnego kontrolera lub kolejnego modelu domenowego tylko po to, żeby było co testować.

Taki format jest też bardzo uczciwy w przygotowaniu do realnej pracy. W komercyjnym rozwoju dużo częściej przychodzisz nie na puste miejsce, ale do już żyjącego kodu. I twoja wartość często nie polega na przepisaniu wszystkiego, ale na nauczeniu się niezawodnej pracy z istniejącym systemem, bez psucia go przy co drugiej zmianie.

3. Suite będzie rosnąć od tanich dowodów do drogich

Żeby mapa nie pozostała abstrakcją, kurs przesuwa się od dołu do góry po cenie weryfikacji. Najpierw — najtańsze i najszybsze dowody bez Spring-magii. Potem — kontrolowane przekroje, gdzie realna staje się infrastruktura jednej warstwy. Następnie — szersze scenariusze integracyjne. Potem — bezpieczeństwo, zewnętrzne integracje i asynchroniczne efekty. I dopiero po tym — późne weryfikacje kontenerowe i dokumentacja z testów. Taka kolejność nie jest przypadkowa. Powtarza dojrzałą logikę zwykłego projektu backendowego.

Jeśli pokazać to jednym obrazkiem, trasa wygląda tak:

flowchart TD
    %% Ogólna idea diagramu: ruch po warstwach testów od dołu do góry,
    %% od szybkich i tanich weryfikacji do droższych i integracyjnych.

    %% A — warstwa startowa: lokalne reguły i testy unit (maksymalnie szybkie)
    A["Lokalne reguły i poziom unit"] --> B["JSON i granica web"]

    %% B — warstwa kontraktów i granicy web: sprawdzamy API/JSON i zachowanie kontrolerów
    B --> C["Data-layer"]

    %% C — warstwa pracy z DB/repozytoriami: sprawdzamy zapytania, filtry, mapowania
    C --> D["Full integration flows"]

    %% D — scenariusze skvozne: kilka warstw systemu razem (drożej, ale uczciwie)
    D --> E["Security, outbound, async"]

    %% E — bezpieczeństwo i integracje: uprawnienia, zewnętrzne klienty, asynchroniczne efekty
    E --> F["Late containers i documentation"]

    %% F — późny etap: weryfikacje kontenerowe, migracje i generowanie dokumentacji z testów

Projekt będzie przy tym poruszać się nie chaotycznie, ale przez zrozumiałe stany bazowe. Nie dla biurokracji, ale dla kontroli. Każda nowa warstwa testów pojawia się na bazie kodu, którą już ustabilizowała poprzednia warstwa. Dzięki temu zestaw testów rośnie jako system, a nie jako kupa niezwiązanych plików.

4. Ten sam flow stanie się częścią kilku poziomów suite

I tu właśnie pojawia się moment, gdzie zazwyczaj pojawia się poczucie: „Okej, kurs jest naprawdę przemyślany". Weź znany scenariusz approve artykułu i public read po publikacji. Przez kurs nie obrośnie on jednym „głównym testem", ale systemem różnych dowodów, każdy ze swoją rolą.

Właśnie to sprawia, że kurs nie jest zbiorem „dziś jedna adnotacja, jutro inna", ale wzrostem profesjonalnego test suite. Zaczynasz widzieć nie tylko osobne testy, ale system warstw pewności wokół jednego produktu. W realnej pracy to odczucie jest bardzo silne: dobry suite nie hałasuje wszystkimi testami jednakowo, podświetla problem na właściwej głębokości 🔦

5. Gdzie ten kurs stoi w linii Spring

Ten kurs nie startuje od absolutnego zera. Jest przeznaczony dla developera, który już potrafi uruchomić aplikację Spring Boot, pisać kontrolery REST, rozumieć DTO, status code, request/response i podstawową strukturę backendu MVC. Mówiąc bardzo krótko: poprzednie kroki nauczyły cię budować zwykły backend. Tu zaczyna się krok, który sprawia, że ta praca jest bardziej profesjonalna.

Dlatego kurs logicznie staje po Spring Boot i Spring REST & MVC. Nie duplikuje ich. Nie będziemy na nowo wyjaśniać, czym jest kontroler, jak działa request mapping i po co są DTO. Tak samo kurs nie próbuje zastąpić Spring Data JPA ani Spring Security. Wręcz przeciwnie, pomaga zobaczyć te tematy jako strefy ryzyka wewnątrz strategii testowania: warstwa danych — osobno, security — osobno, a nie „jakoś później".

I właśnie to czyni kurs dobrym mostem dalej. Po nim testowanie Redis, RabbitMQ, Kafka, Modulith lub bardziej złożonych scenariuszy security przestaje być chaotycznym zoo technik. Masz już warstwową podstawę: potrafisz zapytać, gdzie jest ryzyko i jaka głębokość weryfikacji jest dla niego uczciwa.

6. Czego kurs świadomie nie robi 🤷

Zaufanie do kursu buduje się nie na obietnicy „tu będzie w ogóle wszystko", ale na uczciwych granicach. Pozostajemy wewnątrz klasycznej aplikacji Spring Boot MVC. Nie robimy osobnego kursu z JUnit poza kontekstem Spring Boot. Nie wychodzimy w testowanie wydajności, obciążenia i chaosu. Nie zamieniamy programu w przegląd Kafka, WebFlux, OAuth2, Kubernetes czy infrastruktury CI/CD. To wszystko ważne tematy, po prostu nie temat tej ścieżki.

Dlaczego takie podejście jest przydatne właśnie dla ciebie? Bo utrzymuje skupienie. W pierwszym poważnym kursie o testowaniu bardzo łatwo przeciążyć odbiorców na poziomie Junior narzędziami i ekosystemem tak, że w głowie zostają tylko adnotacje i nazwy bibliotek. Tu cel jest inny: nauczyć się wybierać właściwy poziom weryfikacji dla zwykłego backendu Boot i budować pielęgnowalny suite. Wszystko, co nie wzmacnia bezpośrednio tego celu, świadomie pomijamy.

7. Co dostaniesz po ukończeniu kursu 🏁

Najcenniejszy wynik tego kursu nie brzmi jak lista narzędzi. Pod koniec ścieżki powinieneś umieć patrzeć na zmianę w backendzie i bez paniki odpowiadać na trzy pytania: jakie ryzyko tu się pojawiło, jaki test da minimalnie wystarczający sygnał i jak wbudować ten test w już istniejący suite, nie zamieniając go w kruchy chaos. To bardzo rozpoznawalny profesjonalny nawyk.

Właśnie on odróżnia developera, który „potrafi napisać endpoint", od developera, który umie utrzymywać system w ruchu. W drugiej roli zmienia ci się intonacja nawet w zwykłej pracy. Nie tylko dodajesz feature. Od razu myślisz, gdzie może pęknąć, jaka weryfikacja to złapie i jak nie przepłacić za szerokość testu. To daje spokój przy refaktoryzacji, sensowność na code review i normalną inżynierską pewność siebie, a nie brawurę na szczęście.

8. Potrzebujesz roboczego języka testów️

Po pierwszym poziomie powinna ci zostać nie tylko motywacja, ale konkretna ramka. Widzisz już, dlaczego jeden zielony start niczego nie gwarantuje, gdzie żyją awarie w ContentHub, czym różnią się poziomy testów i jak wybierać minimalnie wystarczającą głębokość weryfikacji. To wystarczy, żeby przestać patrzeć na testowanie jak na „magiczne adnotacje".

Ale mapa sama siebie nie napisze. Dalej potrzebujemy języka, w którym cała ta strategia zamienia się w codzienną praktykę: jak organizować testy, jak formułować scenariusze, jak budować zrozumiałe weryfikacje i jak nie zamieniać suite w zestaw przypadkowych klas. Czyli po mapie naturalnie potrzebny jest silnik — JUnit i podstawowa warstwa narzędziowa, na której potem wyrośnie wszystko inne.

9. Typowe błędy w odbiorze trasy kursu

Błąd nr 1: myślenie, że jeden przekrojowy projekt sprawia, że kurs jest „zbyt wąski".
Wręcz przeciwnie, właśnie jedna domena pozwala uczciwie porównywać różne poziomy testów i widzieć system, a nie zestaw rozproszonych sztuczek.

Błąd nr 2: postrzeganie z góry przygotowanego kodu bliskiego produkcji jako taryfy ulgowej.
To nie uproszczenie dla lenistwa, ale sposób na utrzymanie skupienia na myśleniu testowym. I w realnej pracy prawie zawsze przychodzisz właśnie do już istniejącego kodu.

Błąd nr 3: mierzenie postępu liczbą testów, a nie jakością zamkniętych ryzyk.
Sto dekoracyjnych testów daje mniej pożytku niż dziesięć precyzyjnych. W tym kursie ważniejsza jest nie cyfra, ale rola każdego testu w ogólnej strategii.

Błąd nr 4: oczekiwanie, że kurs zastąpi sobą całe testowanie w ekosystemie Java.
Taki kurs byłby nieuczciwy i bezużyteczny. Tu jest świadoma granica: klasyczny backend Boot MVC i dojrzała warstwowa strategia dla niego.

Błąd nr 5: uznawanie, że mapa i strategia same w sobie dają nawyk.
Po pierwszym dniu masz bardzo silną ramkę. Ale nawyk pojawi się dopiero wtedy, gdy ta ramka zacznie się powtarzać w kodzie, w assertions, w mockach, w slices i w realnych scenariuszach integracyjnych.