Pewnie znasz piramidę testów. Według niej testów jednostkowych powinno być w projekcie najwięcej. Mniej powinno być integracyjnych, a najmniej end-to-end (e2e) ze względu na koszt tworzenia i utrzymania. Jest to dość logiczne podejście. Testy jednostkowe są tanie i proste. Dają bardzo szybką informację zwrotną. Można je też wykonywać lokalnie bez stawiania środowiska testowego, czy łączenia się z zewnętrznymi serwisami. Testy wyższego rzędu są nieco droższe i nie powinny być nadużywane. Czy to jest święta prawda każdego projektu?

 

Rysunek pochodzi z bloga Maćka Gajdzicy, który pisze o systemach embeded. Polecam jego artykuły i wystąpienia!!

 

Testy jednostkowe

Testy jednostkowe sprawdzają odizolowaną funkcjonalność. Nie myśl o testowaniu klas i metod. Myśl o testowaniu scenariuszy. Jeśli tworzysz system e-commerce, taką niezależną funkcjonalnością może być dodawanie VATu do ceny, albo sprawdzanie promocji przed dodaniem produktu do koszyka. Mała rzecz, którą możesz przetestować dokładnie. Weźmy takie doliczanie VATu. Zazwyczaj nie trzymasz lokalnie mapy z różnymi rodzajami podatku, tylko odpowiada za to inny moduł, może nawet serwis. Co stanie się, jeśli odpowiedź nie przyjdzie na czas? Co jeśli będzie błędna? Co jeśli zostanie rzucony wyjątek? I wreszcie, czy wyniki są poprawne dla różnych pozytywnych scenariuszy? Nie musisz wprowadzać aplikacji w dziwny stan. Działasz w izolacji. Łatwo jest zaślepić zależności i sprawdzić, czy Twój kod właściwie reaguje.

 

Testy Integracyjne

Testy integracyjne idą trochę dalej, choć ciągle nie rozpędzają się do sprawdzania całej aplikacji. Działają na kilku poziomach. Mogą łączyć bazę danych i logikę biznesową, albo sprawdzać dwa sąsiadujące  serwisy. Rolą tych testów jest sprawdzenie, czy kawałki naszego systemu do siebie pasują. Testy jednostkowe nie wyłapią wszystkiego…

Dobry przykład testów integracyjnych? Restowe API i praca z bazą danych. Możesz uruchamiać prawdziwą bazę, albo użyć in-memory db. Nie testujesz bazy danych! Testujesz, czy Twój kod poprawnie się z nią komunikuje, zapisuje, czyta, usuwa itd. Możesz korzystać wyłącznie z API, albo dodawać przez API i czytać z bazy, albo odwrotnie. „Interakcje” to dość szerokie pojęcie.

 

Testy e2e

Testy end-to-end to testy systemowe. Sprawdzają, czy cała aplikacja działa jak trzeba. To nie miejsce na odwzorowanie wszystkich możliwych scenariuszy. Ten rodzaj testów sprawdza podstawowy flow aplikacji. Kluczowe operacje. Dla e-commerce może to być wyszukiwanie i wyświetlanie produktu, dodanie go do koszyka i zakup. Można dodać jakieś promocje, sprawdzać dostępne i niedostępne produkty itd. Wszystko zależy od tego, jaką drogą idzie większość użytkowników. Przy tworzeniu tych testów ważna jest współpraca całego zespołu. Te testy są drogie i powolne, trzeba wybrać najlepsze ścieżki.

 

Kiedy odwracać piramidę?

Czy jednak zawsze piramida powinna tak wyglądać? Pewnie domyślasz się, że nie zawsze. W momentach przejściowych projektu dobrze jest zacząć od testów e2e i integracyjnych. Na przykład kiedy nie było prawie żadnych testów, a zamierzamy zrestrukturyzować kod . Struktura kodu będzie się bardzo zmieniać, a jego zachowanie nie powinno, dlatego lepsze będą testy wysokopoziomowe. Mówił o tym Jakub Pilimon na konferencji BITconf w Bydgoszczy podczas prezentacji o refaktoryzacji.

 

Testy są dla nas, a nie my dla testów. Podobnie jak wyznaczanie obowiązkowego poziomu pokrycia kodu testami, trzymanie się zawsze tych samych zasad może nas zwieźć na manowce. Dlatego wszystko zależy od Twojego projektu, w jakiej jest fazie i jakie są jego potrzeby. Jakość ma wiele twarzy 😉