Testy integracyjne: co to jest, rodzaje, przykłady i jak je wykonywać krok po kroku

Czas czytania: około 12 minut

Każdy moduł przeszedł testy jednostkowe, wszystkie są zielone, a po połączeniu ich w całość koszyk nalicza rabat od złej ceny, bo moduł promocji wysyła kwotę brutto, a moduł koszyka spodziewa się netto. Żaden test jednostkowy tego nie złapie, bo każdy z modułów działa poprawnie sam. Łapią to testy integracyjne, czyli testy styków między modułami, usługami i systemami.

W tym tekście wyjaśniamy, czym są testy integracyjne według ISTQB, dlaczego są potrzebne mimo testów jednostkowych, jakie są ich rodzaje i kiedy który wybrać, czym są zaślepki i sterowniki, jak wygląda konkretny przykład, jak je wykonywać krok po kroku i jak wpiąć je w pipeline CI/CD. Piszemy dla testerów, developerów i liderów, którzy decydują, gdzie w piramidzie testów ulokować wysiłek.

Czym są testy integracyjne?

Testy integracyjne to testy wykonywane w celu wykrycia defektów w interfejsach i interakcjach między zintegrowanymi modułami lub systemami; sprawdzają nie to, czy moduł działa, tylko to, czy moduły działają razem.

Tak definiuje je słownik ISTQB. Typowy projekt składa się z wielu modułów pisanych przez różnych programistów, a błędy powstają najczęściej na stykach: w formacie danych, w założeniach o kolejności wywołań, w obsłudze błędów zwracanych przez drugą stronę. Testowanie integracyjne skupia się właśnie na komunikacji między komponentami, a nie na logice wewnątrz każdego z nich.

ISTQB rozróżnia dwa poziomy. Testowanie integracji modułów sprawdza interfejsy między komponentami jednej aplikacji, na przykład między warstwą logiki a repozytorium danych. Testowanie integracji systemów sprawdza interfejsy między osobnymi systemami i organizacjami: sklep i bramka płatności, aplikacja bankowa i system scoringowy, system HR i zewnętrzna wymiana danych. Pierwsze robią zwykle developerzy blisko kodu, drugie testerzy na środowisku integracyjnym, i to drugie najczęściej psuje się na produkcji.

Dlaczego testy integracyjne są potrzebne, skoro moduły przeszły testy jednostkowe?

Testy integracyjne są potrzebne, bo testy jednostkowe sprawdzają każdy moduł w izolacji, z atrapami sąsiadów, więc nie widzą błędów wynikających z różnych założeń dwóch programistów o tym samym interfejsie.

Moduły powstają osobno, u różnych osób, których logika i sposób pracy naturalnie się różnią. Jeden zakłada, że data przychodzi w formacie ISO, drugi wysyła znacznik czasu. Jeden oczekuje pustej listy, drugi zwraca null. Każdy moduł przechodzi swoje testy, a razem nie działają. Do tego dochodzą zmiany wymagań w trakcie pracy, interfejsy z bazą danych i systemami zewnętrznymi, obsługa wątków i limity czasu odpowiedzi, których w izolacji nikt nie testował.

Testy integracyjne można zacząć wcześnie, bez czekania, aż powstaną wszystkie moduły, bo brakujące zastępuje się zaślepkami i sterownikami. To ważne z jednego powodu: błąd interfejsu znaleziony przy integracji dwóch modułów naprawia się w godzinę, ten sam błąd znaleziony w testach systemowych albo na produkcji wymaga szukania winnego modułu wśród kilkunastu.

Liczby z projektu dla Argos, sklepu internetowego, potwierdzone przez klienta. Regresja skróciła się nie dlatego, że testów było mniej, tylko dlatego, że większość sprawdzania logiki zeszła z wolnych testów interfejsu na szybkie testy integracyjne i API.

Jakie są rodzaje testów integracyjnych?

Są dwa główne podejścia: Big Bang, w którym integruje się wszystkie moduły naraz, oraz przyrostowe, w którym dołącza się je po jednym, z góry na dół (top-down), z dołu do góry (bottom-up) albo z obu stron jednocześnie (sandwich).

Big Bang sprawdza się w małych systemach, gdzie liczba modułów jest niewielka i błąd łatwo namierzyć. W większych projektach wybiera się podejście przyrostowe, bo każdy dołączony moduł jest testowany od razu i wiadomo, co zepsuło integrację. W praktyce zespołów pracujących w sprintach integracja i tak jest przyrostowa, bo moduły powstają w różnym tempie, więc wybór sprowadza się do tego, czy zaczynacie od interfejsu użytkownika, czy od bazy danych.

Czym są zaślepki, sterowniki i mocki?

Zaślepki, sterowniki i mocki to atrapy modułów, których jeszcze nie ma albo których nie chcecie uruchamiać w teście: zaślepka odpowiada na wywołania testowanego modułu, sterownik go wywołuje, a mock dodatkowo sprawdza, czy został wywołany tak, jak powinien.

Zaślepki i sterowniki nie implementują logiki modułu, tylko symulują jego komunikację. Ich pisanie bywa czasochłonne, dlatego przy integracji z bazą danych albo kolejką coraz częściej zamiast atrapy uruchamia się prawdziwą zależność w kontenerze na czas testu. Atrapa mówi, jak moduł powinien się zachować, kontener pokazuje, jak zachowuje się naprawdę.

Jak wygląda przykład testu integracyjnego?

Przykład: moduł koszyka wysyła do modułu rabatów kwotę i kod promocyjny, a test integracyjny sprawdza, czy odpowiedź ma właściwy format, czy koszyk poprawnie ją przetwarza i co się dzieje, gdy moduł rabatów zwróci błąd.

Trzy typowe scenariusze z projektów, które prowadzimy. Pierwszy: sklep internetowy, moduł koszyka i moduł promocji. Drugi: aplikacja i baza danych, czyli czy zapis przez repozytorium daje się odczytać z właściwymi typami i kodowaniem. Trzeci: integracja systemów, sklep i zewnętrzna bramka płatności, gdzie testuje się nie tylko ścieżkę pozytywną, ale też odrzucenie płatności, przekroczenie czasu odpowiedzi i podwójne wysłanie tego samego żądania.

Scenariusz: koszyk i modul rabatow, integracja przez API
Dane wejsciowe: koszyk 200,00 PLN, kod WIOSNA10
Wywolanie:  POST /rabaty/nalicz  {"kwota_netto": 200.00, "kod": "WIOSNA10"}
Oczekiwane: 200 OK, {"rabat": 20.00, "kwota_po_rabacie": 180.00}
Sprawdzamy: koszyk pokazuje 180,00 PLN, podsumowanie zamowienia 180,00 PLN

Scenariusz negatywny: modul rabatow niedostepny
Wywolanie:  POST /rabaty/nalicz  -> 503 Service Unavailable
Oczekiwane: koszyk pokazuje cene bez rabatu i komunikat, zamowienie mozna zlozyc
Bledne:     koszyk pokazuje 0,00 PLN albo blad serwera na stronie koszyka

Drugi scenariusz wygląda podobnie, tylko zamiast HTTP mamy zapytanie do bazy: zapis rekordu z polskimi znakami i datą, odczyt, porównanie pól. Trzeci wymaga środowiska testowego bramki płatności i danych testowych kart. Więcej przykładów na poziomie API pokazujemy w tekście Postman: testy integracyjne i testy API.

Jak wykonywać testy integracyjne krok po kroku?

Testy integracyjne wykonuje się w pięciu krokach: plan integracji z kolejnością modułów, projekt scenariuszy dla każdego interfejsu, przygotowanie atrap i danych, wykonanie z rejestrowaniem defektów, retest po poprawkach, aż wszystkie interfejsy przejdą.

Kroki 4 i 5 powtarza się aż do pomyślnego zakończenia. Plan z kroku 1 najlepiej trzymać w planie testów obok testów jednostkowych i systemowych, żeby było jasne, który poziom odpowiada za który rodzaj błędu.

Czym różnią się testy integracyjne od jednostkowych, systemowych i end to end?

Testy jednostkowe sprawdzają jeden moduł w izolacji, integracyjne sprawdzają styki między modułami, systemowe sprawdzają cały system jako całość, a end to end sprawdzają pełną ścieżkę użytkownika przez wiele systemów.

Najczęstsze nieporozumienie dotyczy testów systemowych: w nich wszystkie moduły są już zintegrowane i sprawdza się system jako całość, natomiast testy integracyjne sprawdzają same połączenia, często zanim system w całości istnieje. O najwyższej warstwie piszemy w tekście o testach end to end, a o rozłożeniu wysiłku między poziomami w tekście o piramidzie testów.

Jak wpiąć testy integracyjne w CI/CD?

W CI/CD testy integracyjne uruchamia się po testach jednostkowych i przed testami systemowymi, na zależnościach w kontenerach albo na środowisku integracyjnym, a styki z systemami zewnętrznymi zabezpiecza testami kontraktowymi zamiast pełną integracją przy każdej zmianie.

• Kolejność w pipeline: kompilacja, testy jednostkowe, testy integracyjne na kontenerach, wdrożenie na środowisko, smoke test, testy systemowe i E2E krytycznych ścieżek.
• Testy kontraktowe: zamiast uruchamiać prawdziwą bramkę płatności przy każdym commicie, obie strony uzgadniają kontrakt interfejsu i każda testuje zgodność ze swojej strony. Zmiana kontraktu blokuje pipeline zamiast psuć produkcję.
• Testy API jako testy integracyjne: większość integracji między usługami idzie przez HTTP, więc testy API w narzędziach takich jak Postman czy REST Assured są najtańszą formą testów integracyjnych.
• Dane i środowiska: testy integracyjne padają najczęściej nie przez kod, tylko przez brak danych, zajęte środowisko albo niedostępny system zewnętrzny. Bez uporządkowania tej warstwy pipeline będzie czerwony z powodów, które nikogo nie interesują.

To jest dokładnie ruch, o którym piszemy w tekście o shift left testing: przesunięcie sprawdzania logiki z wolnych testów interfejsu na szybkie testy integracyjne i API, uruchamiane przy każdej zmianie. Jeżeli chcecie wdrożyć to systemowo, pomagamy przez automatyzację testów API i budowę procesów CI/CD.

Kto je pisze? Integrację modułów w obrębie jednej aplikacji najczęściej testują developerzy blisko kodu, a integrację systemów, na przykład z bramką płatności albo systemem zewnętrznym, testerzy na środowisku integracyjnym. Ten poziom należy do najbardziej opłacalnych w automatyzacji: testy są szybsze i stabilniejsze niż testy interfejsu, a większość integracji idzie przez API.

Jakie są najczęstsze błędy w testach integracyjnych?

Najczęstsze błędy to testowanie tylko ścieżki pozytywnej, atrapy, które odpowiadają inaczej niż prawdziwy moduł, brak testów przekroczenia czasu i błędów drugiej strony, oraz traktowanie testów systemowych jako zamiennika testów integracyjnych.

1. Tylko ścieżka pozytywna. Interfejs działa, gdy druga strona odpowiada poprawnie. Test integracyjny ma sprawdzić też, co się dzieje przy błędzie 500, pustej odpowiedzi, przekroczeniu czasu i duplikacie żądania.
2. Atrapa kłamie. Zaślepka zwraca to, co programista zakładał, a nie to, co prawdziwy moduł zwraca. Kontrakt trzeba potwierdzić z właścicielem drugiego modułu albo uruchomić prawdziwą zależność w kontenerze.
3. Brak testów integracji systemów. Zespół testuje styki między własnymi modułami, a integracja z bankiem, ERP albo bramką płatności jest sprawdzana dopiero na produkcji.
4. Big Bang w dużym systemie. Wszystko łączone naraz i tydzień szukania, który z dwudziestu modułów zawinił.
5. Zgłoszenie bez żądania i odpowiedzi. Defekt interfejsu opisany słowami zamiast surowym żądaniem i odpowiedzią wraca do testera z pytaniem o szczegóły.
6. Testy integracyjne, które nie żyją w pipeline. Wykonane raz, ręcznie, przy pierwszej integracji, a potem nigdy więcej, choć interfejsy zmieniają się w każdym sprincie.

Kompetencje w tym obszarze budujemy na szkoleniu Testy jednostkowe i integracyjne dla programistów oraz Wprowadzenie do testowania API. Wiedzę dla liderów jakości publikujemy na portalu Strefa QA.

Powiązane na blogu Quality Island

• Postman: testy integracyjne i testy API w praktyce
• Testy end to end (E2E): co to jest, kiedy je uruchamiać i ile ich naprawdę potrzebujecie
• Poziomy testowania oprogramowania: od testów jednostkowych po akceptacyjne
• Piramida testów i techniki projektowania testów
• Shift left testing: co to jest, zalety, wady i jak wdrożyć krok po kroku

Pełna lista źródeł

• ISTQB Glossary, hasła integration testing, component integration testing, stub i driver
• Martin Fowler, IntegrationTest oraz ContractTest
• Wikipedia, Integration testing
• Testcontainers, biblioteka do uruchamiania prawdziwych zależności w kontenerach na czas testu
• Dane własne Quality Island z projektu dla Argos, e-commerce, liczby potwierdzone przez klienta