Debugger to narzędzie programistyczne do lokalizowania przyczyny błędu w kodzie: umożliwia zatrzymanie programu w określonym miejscu (breakpoint), wykonanie krokowe, podgląd stosu wywołań i wartości zmiennych. Z tego powodu najnaturalniej łączy się go z sytuacją, w której analizujemy niewielki fragment programu i chcemy szybko sprawdzić, dlaczego dana funkcja lub metoda działa nieprawidłowo.
Testy jednostkowe dotyczą pojedynczych jednostek (np. funkcji, klasy, modułu) i zwykle są uruchamiane blisko kodu źródłowego, często przez programistę. Gdy test jednostkowy nie przechodzi, łatwo odtworzyć problem w małej skali i użyć debuggera, aby znaleźć dokładną instrukcję lub warunek powodujący błąd.
Odpowiedzi rozpraszające są mniej trafne, bo zwykle mają inny cel i inną skalę:
- Testy integracyjne sprawdzają współdziałanie kilku elementów (np. moduł + baza danych, kilka usług). Debugger może się pojawić, ale trudniej jednoznacznie wskazać winny fragment, bo błąd może wynikać z kontraktu między komponentami, konfiguracji albo danych.
- Testy systemowe obejmują cały system jako całość. Na tym poziomie częściej analizuje się logi, monitoring, konfigurację środowiska i scenariusze użytkownika; bezpośrednie debugowanie bywa możliwe, ale jest mniej typowe jako "najczęstsze" narzędzie.
- Testy akceptacyjne mają potwierdzić spełnienie wymagań biznesowych, zwykle z perspektywy użytkownika/klienta. Tu podstawą są kryteria akceptacji i scenariusze, a nie debugowanie kodu.
Wskazówka egzaminacyjna: jeśli pytanie łączy debugger z rodzajem testów, myśl o poziomie najbliższym kodowi i najszybszej diagnostyce przyczyny błędu – to najczęściej prowadzi do testów jednostkowych.
