TDD: co to jest, zasady testowania i metodologia

Co to jest TDD?

Test-Driven Development — to praktyka tworzenia oprogramowania, w której zautomatyzowane testy określają pisanie kodu produkcyjnego. W przeciwieństwie do tradycyjnego podejścia, gdzie kod jest pisany, a następnie testowany, TDD odwraca kolejność: najpierw pisany jest test, potem kod, który ten test przechodzi.

Twórcą TDD jest Kent Beck, który sformułował tę praktykę pod koniec lat 90. XX wieku w ramach metodologii Extreme Programming (XP). W książce „Test-Driven Development: By Example" (2002) Beck opisał pięć reguł TDD, które stały się kanoniczne: pisz test przed kodem produkcyjnym, pisz dokładnie tyle kodu, ile potrzeba do zaliczenia testu, i refaktoryzuj po każdym cyklu.

Kluczowe zasady TDD

Pierwsza zasada — test określa interfejs. Programista jest zmuszony myśleć o tym, jak komponent będzie używany, zanim pomyśli o tym, jak jest zaimplementowany. To kształtuje czyste API od samego początku.

TDD jako technika projektowania

Druga zasada — minimalna implementacja. Gdy test jest napisany, programista pisze dokładnie tyle kodu produkcyjnego, ile potrzeba do jego zaliczenia — ani linijki więcej. Zapobiega to przedwczesnej abstrakcji i nadmiernej złożoności, którą Martin Fowler nazywa Speculative Generality.

Różnica między TDD a zwykłym testowaniem

Kluczowa różnica między TDD a testowaniem „post factum" — dyscyplina kolejności. W TDD test nie tylko sprawdza kod — kieruje jego strukturą. Według badań Microsoft Research (Nagappan et al., 2008), zespoły stosujące TDD wykazują zmniejszenie gęstości defektów o 40–90% w porównaniu z zespołami stosującymi tradycyjne podejście.

Cykl Red-Green-Refactor

Cykl Red-Green-Refactor — to trzyetapowa sekwencja powtarzana dla każdego nowego testu. Red: napisz test, który nie przechodzi. Green: napisz minimalny kod, aby test przeszedł. Refactor: ulepsz kod bez zmiany jego zachowania.

Faza Red: pisanie nieudanego testu

Programista pisze test, który sprawdza jeszcze niezaimplementowaną funkcjonalność. Na tym etapie test powinien upaść — to potwierdza, że test rzeczywiście coś sprawdza. W środowisku programowania Android framework JUnit 5 pokazuje czerwoną indykację dla nieudanych testów, co dało nazwę fazie.

class CalculatorTest {
    fun testAddition() {
        val result = Calculator().add(2, 3)
        Assertions.assertEquals(5, result)
    }
}

Faza Green: minimalna implementacja

Na tym etapie pisany jest minimalny kod produkcyjny wystarczający do zaliczenia testu. Żadnej nadmiarowości — tylko to, co jest potrzebne do zielonej indykacji. Jeśli implementacja może być stałą — niech będzie stałą. Refaktoryzacja nastąpi na następnym kroku, gdy pojawią się nowe testy.

class Calculator {
    fun add(a: Int, b: Int): Int {
        return a + b
    }
}

Faza Refactor: ulepszanie bez ryzyka

Zielony test to ubezpieczenie dla refaktoryzacji. Programista może przepisać implementację, zoptymalizować wydajność lub poprawić czytelność, będąc pewnym, że test natychmiast wykryje każde odstępstwo od oczekiwanego zachowania. W programowaniu mobilnym na Androidzie ta faza jest szczególnie ważna dla wyodrębniania wspólnych interfejsów i zmniejszania duplikacji kodu.

Zalety TDD w programowaniu mobilnym

Stosowanie TDD w projektach mobilnych daje wymierne korzyści, potwierdzone zarówno badaniami akademickimi, jak i praktyką wiodących studiów programistycznych.

Zmniejszenie gęstości defektów

Badanie IBM (Bhat & Nagappan, 2006) na czterech projektach przemysłowych wykazało, że zespoły stosujące TDD popełniają 40% mniej defektów w porównaniu z podobnymi zespołami pracującymi tradycyjnie. Dla programowania mobilnego, gdzie koszt naprawy błędu po wydaniu w Google Play jest znacznie wyższy niż na etapie pisania kodu, ta metryka jest krytyczna.

Dokumentowanie kodu poprzez testy

Testy napisane według TDD służą jako żywa dokumentacja API. Programista przychodzący do projektu może przeczytać testy i zrozumieć, jak każdy komponent powinien być używany. Jest to szczególnie cenne w warunkach wysokiej rotacji zespołu — typowego problemu studiów mobilnych.

Pewna refaktoryzacja

Pokrycie kodu testami przekraczające 90% pozwala programistom przeprowadzać refaktoryzację bez strachu przed zepsuciem czegoś. Google w swojej książce „Software Engineering at Google" (2020) nazywa pokrycie testowe kluczowym czynnikiem umożliwiającym utrzymanie bazy kodu w czystości w projektach z milionami linii kodu.

Narzędzia i frameworki dla TDD

Ekostystem TDD w programowaniu mobilnym obejmuje narzędzia do testów jednostkowych, mockinga i sprawdzania komponentów UI — zarówno dla Androida, jak i iOS.

Wybór frameworka dla Androida

Dla projektów Android na Kotlin standardowy stos obejmuje JUnit 5 + MockK. MockK jest preferowany nad Mockito, ponieważ obsługuje funkcje Kotlin pierwszej klasy — sealed class, korutyny i suspend-funkcje bez dodatkowej konfiguracji.

Narzędzia dla iOS

W programowaniu iOS TDD jest realizowane poprzez XCTest — wbudowany framework Apple, który udostępnia asercje, klasy testowe i integrację z CI/CD przez Xcode Server lub GitHub Actions. Do mockowania na iOS stosuje się biblioteki Cuckoo i OHHTTPStubs.

Przykłady kodu z TDD w Kotlinie

Rozważmy rzeczywisty scenariusz TDD w Kotlinie dla Androida — testowanie repozytorium użytkowników. Najpierw piszemy test, następnie — implementację przechodzącą ten test.

Krok 1: test dla UserRepository

class UserRepositoryTest {
    private val api = mockk<UserApi>()
    private val dao = mockk<UserDao>()
    private val repo = UserRepository(api, dao)

    fun `when api returns user then cache and emit`() = runTest {
        val user = User(1, "Alice")
        coEvery { api.getUser(1) } returns user
        every { dao.insert(user) } returns Unit

        val result = repo.getUser(1)

        assertEquals(user, result)
        verify { dao.insert(user) }
    }
}

Krok 2: minimalna implementacja

class UserRepository(
    private val api: UserApi,
    private val dao: UserDao
) {
    suspend fun getUser(id: Int): User {
        val user = api.getUser(id)
        dao.insert(user)
        return user
    }
}

Krok 3: test dla buforowania z trybem offline

Po zaliczeniu pierwszego testu dodajemy drugi — sprawdzamy zachowanie przy błędzie sieci. Teraz test określa, że przy awarii API repozytorium powinno zwrócić dane z pamięci podręcznej.

fun `when api fails then return cached user`() = runTest {
    val cached = User(1, "Cached Alice")
    coEvery { api.getUser(1) } throws IOException()
    every { dao.getById(1) } returns cached

    val result = repo.getUser(1)

    assertEquals(cached, result)
}

Typowe błędy przy wdrażaniu TDD

Przejście na TDD wiąże się z typowymi błędami, które mogą zniweczyć wszystkie zalety metodologii. Zrozumienie tych pułapek pomaga zespołom wdrażać praktykę efektywniej.

Zbyt duże testy

Pierwszy i najczęstszy antywzór — testowanie zbyt dużego zakresu funkcjonalności w jednym teście. Test powinien sprawdzać dokładnie jedno twierdzenie (jeden asercja). Jeśli test upada, programista powinien wiedzieć, co dokładnie się zepsuło, bez dodatkowego debugowania.

Ignorowanie czerwonej fazy

Drugi błąd — pisanie testu, który początkowo przechodzi. Jeśli test nie był czerwony choć raz, nie ma pewności, że w ogóle coś sprawdza. Zasada: nigdy nie ufaj testowi, którego nie widziałeś upadającym.

Pomijanie refaktoryzacji

Trzeci typowy błąd — zatrzymanie się na zielonej fazie. Refaktoryzacja to nie opcjonalny, ale obowiązkowy etap cyklu. Bez niej baza kodu degraduje, testy stają się kruche, a zalety TDD są tracone.

• Testowanie implementacji, a nie zachowania — testy przywiązują się do szczegółów i psują przy każdej refaktoryzacji
• Brak testów dla przypadków brzegowych — puste listy, wartości null, warunki graniczne pozostają niepokryte
• Ignorowanie szybkości testów — wolne testy spowalniają pętlę sprzężenia zwrotnego i zabijają dyscyplinę TDD