TDD: co to je, principy testování a metodologie

Co je TDD?

Test-Driven Development — je praktika vývoje softwaru, při které automatizované testy určují psaní produkčního kódu. Na rozdíl od tradičního přístupu, kde se kód nejprve napíše a poté testuje, TDD obrací pořadí: nejprve se napíše test, poté kód, který tento test projde.

Za zakladatele TDD je považován Kent Beck, který tuto praktiku formuloval na konci 90. let 20. století v rámci metodologie Extreme Programming (XP). V knize „Test-Driven Development: By Example" (2002) Beck popsal pět pravidel TDD, která se stala kanonickými: napiš test před produkčním kódem, napiš přesně tolik kódu, kolik je potřeba k průchodu testu, a refaktoruj po každém cyklu.

Klíčové principy TDD

První princip — test definuje rozhraní. Vývojář je nucen přemýšlet o tom, jak bude komponenta používána, dříve než přemýšlí o tom, jak je implementována. To formuje čisté API od samého začátku.

TDD jako technika návrhu

Druhý princip — minimální implementace. Když je test napsán, vývojář napíše přesně tolik produkčního kódu, kolik je potřeba k jeho průchodu — ani řádek navíc. To zabraňuje předčasné abstrakci a nadměrné komplexitě, kterou Martin Fowler nazývá Speculative Generality.

Rozdíl mezi TDD a běžným testováním

Klíčový rozdíl mezi TDD a testováním „dodatečně" — disciplína pořadí. V TDD test nejen kontroluje kód — ale řídí jeho strukturu. Podle výzkumu Microsoft Research (Nagappan et al., 2008) vykazují týmy aplikující TDD snížení hustoty defektů o 40–90 % ve srovnání s týmy používajícími tradiční přístup.

Cyklus Red-Green-Refactor

Cyklus Red-Green-Refactor — je tříkroková sekvence opakovaná pro každý nový test. Red: napiš test, který neprojde. Green: napiš minimální kód, aby test prošel. Refactor: vylepši kód bez změny jeho chování.

Fáze Red: psaní padajícího testu

Vývojář napíše test, který kontroluje dosud neimplementovanou funkcionalitu. V této fázi by měl test padnout — to potvrzuje, že test skutečně něco kontroluje. Ve vývojovém prostředí Android framework JUnit 5 zobrazuje červenou indikaci pro padlé testy, což dalo fázi jméno.

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

Fáze Green: minimální implementace

V této fázi se píše minimální produkční kód dostatečný pro průchod testu. Žádná redundance — pouze to, co je potřeba pro zelenou indikaci. Pokud implementace může být konstanta — ať je konstanta. Refaktorování proběhne v dalším kroku, když se objeví nové testy.

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

Fáze Refactor: vylepšení bez rizika

Zelený test je pojištění pro refaktorování. Vývojář může přepsat implementaci, optimalizovat výkon nebo zlepšit čitelnost, s jistotou, že test okamžitě odhalí jakoukoli odchylku od očekávaného chování. V mobilním vývoji na Androidu je tato fáze obzvláště důležitá pro vyčlenění společných rozhraní a snížení duplicity kódu.

Výhody TDD v mobilním vývoji

Aplikace TDD v mobilních projektech přináší měřitelné výhody, potvrzené jak akademickým výzkumem, tak praxí předních vývojářských studií.

Snižení hustoty defektů

Výzkum IBM (Bhat & Nagappan, 2006) na čtyřech průmyslových projektech ukázal, že týmy používající TDD dělají o 40 % méně defektů ve srovnání s podobnými týmy pracujícími tradičně. Pro mobilní vývoj, kde jsou náklady na opravu chyby po vydání v Google Play výrazně vyšší než ve fázi psaní kódu, je tato metrika kritická.

Dokumentace kódu prostřednictvím testů

Testy napsané podle TDD slouží jako živá dokumentace API. Vývojář přicházející do projektu může číst testy a pochopit, jak má být každá komponenta používána. To je obzvláště cenné v podmínkách vysoké fluktuace týmu — typického problému mobilních studií.

Sebevědomé refaktorování

Pokrytí kódu testy přesahující 90 % umožňuje vývojářům provádět refaktorování bez strachu, že něco rozbijí. Google ve své knize „Software Engineering at Google" (2020) nazývá pokrytí testy klíčovým faktorem, který umožňuje udržovat kódovou základnu čistou v projektech s miliony řádků kódu.

Nástroje a frameworky pro TDD

Ekosystém TDD v mobilním vývoji zahrnuje nástroje pro unit testy, mocking a kontrolu UI komponent — jak pro Android, tak pro iOS.

Výběr frameworku pro Android

Pro Android projekty v Kotlinu standardní stack zahrnuje JUnit 5 + MockK. MockK je preferován před Mockito, protože podporuje funkce Kotlin první třídy — sealed class, korutiny a suspend-funkce bez dodatečné konfigurace.

Nástroje pro iOS

Ve vývoji pro iOS je TDD implementován prostřednictvím XCTest — vestavěného frameworku Apple, který poskytuje aserce, testovací třídy a integraci s CI/CD přes Xcode Server nebo GitHub Actions. Pro mocking na iOS se používají knihovny Cuckoo a OHHTTPStubs.

Příklady kódu TDD v Kotlinu

Podívejme se na reálný scénář TDD v Kotlinu pro Android — testování uživatelského repozitáře. Nejprve napíšeme test, poté — implementaci, která tímto testem projde.

Krok 1: test pro 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: minimální implementace

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 pro cachování s offline režimem

Po průchodu prvního testu přidáme druhý — kontrolujeme chování při chybě sítě. Nyní test určuje, že při pádu API by měl repozitář vrátit data z mezipaměti.

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)
}

Typické chyby při zavádění TDD

Přechod na TDD je doprovázen typickými chybami, které mohou anulovat všechny výhody metodologie. Pochopení těchto nástrah pomáhá týmům zavádět praktiku efektivněji.

Příliš velké testy

První a nejrozšířenější anti-vzor — testování příliš velkého rozsahu funkcionality v jednom testu. Test by měl kontrolovat přesně jedno tvrzení (jednu aserci). Pokud test spadne, vývojář by měl vědět, co přesně se rozbilo, bez dodatečného ladění.

Ignorování červené fáze

Druhá chyba — napsání testu, který od začátku prochází. Pokud test nebyl alespoň jednou červený, není jistota, že vůbec něco kontroluje. Pravidlo: nikdy nevěř testu, který jsi neviděl padat.

Vynechání refaktorování

Třetí typická chyba — zastavení v zelené fázi. Refaktorování není volitelná, ale povinná fáze cyklu. Bez něj kódová základna degraduje, testy se stávají křehkými a výhody TDD se ztrácejí.

• Testování implementace, nikoli chování — testy se vážou na detaily a při každém refaktorování se rozbijí
• Chybějící testy pro okrajové případy — prázdné seznamy, null hodnoty, hraniční podmínky zůstávají nepokryté
• Ignorování rychlosti testů — pomalé testy zpomalují zpětnou vazbu a zabíjejí disciplínu TDD