Redakcja
Czym jest zasada Tetrisa?
Zasada Tetrisa to podejście do automatyzacji testów, które zakłada, że każdy test powinien zostać zaimplementowany na możliwie najniższym poziomie piramidy testów, czyli tam, gdzie jest szybki, tani i łatwy do utrzymania i daje jasny sygnał zwrotny. Jej nazwa to czytelna metafora. Tak jak w grze Tetris chcemy układać klocki jak najniżej, tak w testach powinniśmy unikać piętrzenia się testów na najwyższych, najmniej stabilnych warstwach.
Zasada ta jest bezpośrednią praktyczną interpretacją piramidy testów, której podstawę stanowią testy jednostkowe, środek - testy integracyjne lub serwisowe, a wierzchołek - testy UI i E2E.
Dlaczego warto pisać testy jak najniżej?
- Szybkość.
Testy jednostkowe są błyskawiczne. W przeciwieństwie do testów E2E, które często wymagają pełnego wdrożenia aplikacji lub złożonych środowisk testowych, testy niskopoziomowe mogą być odpalane lokalnie, natychmiast po zapisaniu kodu. Efekt? Szybsze wykrywanie defektów i lepszy flow programisty. - Koszt.
Im wyższy poziom testu, tym wyższy poziom jego napisania, uruchomienia i utrzymania. To także więcej zależności, większa złożoność środowiskowa i większe ryzyko fałszywych negatywów. Testy jednostkowe to nie tylko mniejsze koszty infrastruktury, ale także mniej czasu straconego na debugowanie niejednoznacznych błędów. - Przejrzystość.
Test, który zawodzi w UI, nie zawsze informuje o źródle problemu. Test jednostkowy (o ile jest dobrze napisany) wskazuje dokładnie, co przestało działać i dlaczego. To ogranicza czas spędzony na analizie przyczyn awarii.
Czy to znaczy, że testy UI są zbędne? Nie. Testy E2E czy UI są potrzebne, by potwierdzić działanie najważniejszych ścieżek biznesowych, sprawdzić integrację między warstwami systemu, wykryć błędy konfiguracji lub regresje w interakcji komponentów. Ale zamiast pokrywać nimi wszystkie scenariusze, lepiej ograniczyć je do przypadków krytycznych i budować pokrycie od dołu piramidy.
Zasada Tetrisa w praktyce
Po pierwsze walidacja formularzy. Zamiast testować ją przez UI, wydziel logikę walidacji do funkcji lub klasy i pokryj ją testami jednostkowymi.
Po drugie reguły biznesowe. Zamknij je w warstwie domenowej, niezależnej od UI i bazy danych oraz testuj jako jednostki lub małe moduły.
Po trzecie zapytania do bazy. Testuj je na poziomie repozytoriów lub warstwy dostępu do danych, nie przez interfejs użytkownika.
I po czwarte BDD (Behavior-Driven Developmen). Nie wymaga on Selenium, dlatego zastosuj podejście Given-When-Then w testach jednostkowych, żeby zachować przejrzystość bez kosztów integracyjnych.
Architektoniczne konsekwencje zasady Tetrisa
Zasada Tetrisa nie kończy się na testach, wpływa również na sposób projektowania systemów. Im lepiej oddzielone są komponenty, tym łatwiej testować je w izolacji. Dlatego wyciągaj logikę do czystych funkcji, ogranicz zależności kontekstowe (np. baza danych, framework UI), i projektuj komponenty tak, by można było je uruchamiać i testować niezależnie. To wszystko pozwala pisać testy niżej i lepiej.
Na co uważać?
Zasada Tetrisa nie zwalnia z myślenia. Trzeba stosować ją świadomie i nie popaść w automatyzm. Nie każdy test da się sprowadzić do jednostki, więc nie ignoruj potrzeby testów integracyjnych i E2E tam, gdzie są uzasadnione. Pamiętaj, że zbyt agresywne mockowanie potrafi wypaczyć sens testów, a przenoszenie wszystkiego do jednostek bez refleksji może skutkować ignorowaniem realnych problemów integracyjnych.
Można posłużyć się pytaniami:
- Czy ten test naprawdę musi być testem E2E?
- Czy mogę wydzielić logikę i pokryć ją testem jednostkowym?
- Gdzie znajduje się źródło potencjalnego defektu i czy mogę je przetestować niżej?
- Czy struktura mojego kodu umożliwia niskopoziomowe testowanie?
- Czy testy, które piszę, dają szybką i jednoznaczną informację zwrotną?
Podsumowanie
Zasada Tetrisa może stać się przydatnym filtrem do podejmowania lepszych decyzji. Zachęca do zadawania pytania: "jak nisko mogę zejść?" i prowadzi do projektowania bardziej testowalnych, modularnych i tańszych w utrzymaniu systemów.
