Testowanie jednostkowe (unit testing) to testowanie najmniejszych fragmentów kodu - pojedynczych funkcji, metod, klas - w izolacji od reszty systemu i zależności zewnętrznych. Piszą je developerzy, zwykle równolegle z kodem, a uruchamia automatycznie pipeline przy każdej zmianie.
Po co ta wiedza analitykowi, skoro testów jednostkowych nie pisze? Z dwóch powodów. Po pierwsze, piramida testów: im niżej wykryty błąd, tym tańsza poprawka. Błąd znaleziony w unit teście kosztuje minuty, ten sam błąd na UAT kosztuje dni, a na produkcji potrafi kosztować klientów. Po drugie, reguły biznesowe, które analityk opisuje, lądują ostatecznie w funkcjach pokrytych unit testami - precyzyjnie opisane przypadki brzegowe przekładają się wprost na przypadki testowe developera.
W MediFlow funkcja wyliczająca dostępne sloty wizyt ma 14 testów jednostkowych: urlop lekarza, święto państwowe, wizyta nachodząca na przerwę, slot dokładnie na granicy końca pracy, dwie rezerwacje tego samego terminu. Większość tych przypadków pochodzi wprost z tabeli reguł, którą analityk spisał z kierowniczkami rejestracji - developer sam nie wymyśliłby, że w jednej z przychodni w środy przyjmuje się tylko do 14:00.
Częsta pomyłka: oczekiwanie, że testy jednostkowe wykryją błędy procesu biznesowego end-to-end. Nie wykryją - sprawdzają fragmenty w izolacji, a błędy integracyjne i procesowe łapią wyższe poziomy testów. Druga: nazywanie unit testem testu, który sięga do prawdziwej bazy danych. To już test integracyjny, z innym kosztem i innym czasem wykonania.