Ola Kunysz
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 VAT-u do ceny albo sprawdzanie promocji przed dodaniem produktu do koszyka. Mała rzecz, którą możesz przetestować dokładnie. Weźmy takie doliczanie VAT-u. 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.
Powyższy artykuł jest przedrukiem (po niewielkich zmianach) z bloga testerskiego Szkoła Testów.
