Gdy moduł logowania i moduł zamówień aplikacji zostały przetestowane oddzielnie, testowanie integracyjne weryfikuje ich współdziałanie: użytkownik loguje się i składa zamówienie, a moduł zamówień poprawnie otrzymuje tożsamość uwierzytelnionego użytkownika. Dane testowe i oczekiwane wyniki obejmują interfejsy — kontrakty API, połączenia z bazą danych i wspólne formaty danych. Celem jest ujawnienie defektów w interfejsach oraz w interakcjach między zintegrowanymi komponentami lub systemami.
Jaka jest różnica między testowaniem integracyjnym a testowaniem systemowym? Testowanie integracyjne koncentruje się na interfejsach i interakcjach między zintegrowanymi komponentami lub systemami. Testowanie systemowe sprawdza kompletny, w pełni zintegrowany system względem jego wymagań. Najpierw następuje integracja; testowanie systemowe odbywa się później, gdy wszystko jest już zintegrowane.
Czym jest podejście „od góry do dołu” (top-down) lub „od dołu do góry” (bottom-up)? To strategie integracji. Podejście top-down zaczyna się od modułów najwyższego poziomu i wykorzystuje zaślepki (stuby) dla modułów niższych; podejście bottom-up zaczyna się od modułów niższych i wykorzystuje sterowniki (drivery). Oba mają na celu stopniowe ujawnianie defektów interfejsów.
Czy testy integracyjne wymagają prawdziwych interfejsów? Idealnie tak, ale gdy prawdziwe moduły nie są jeszcze dostępne, stosuje się zaślepki i sterowniki. Ryzyko polega na tym, że defekty ukryte przez zamienniki ujawnią się dopiero podczas testowania systemowego.
Dlaczego defekty interfejsów zdarzają się tak często? Ponieważ komponenty są często rozwijane równolegle, a założenia dotyczące formatów danych, obsługi błędów i zależności czasowych rzadko są precyzyjnie udokumentowane. Testowanie integracyjne uwidacznia te założenia.