TDD: mi ez, tesztelési elvek és metodológia

Mi az a TDD?

Test-Driven Development — egy szoftverfejlesztési gyakorlat, ahol az automatizált tesztek határozzák meg a termelési kód írását. Ellentétben a hagyományos megközelítéssel, ahol a kódot először megírják, majd tesztelik, a TDD megfordítja a sorrendet: először a tesztet írják meg, majd azt a kódot, amely átmegy ezen a teszten.

A TDD megalapítójának Kent Becket tartják, aki ezt a gyakorlatot az 1990-es évek végén fogalmazta meg az Extreme Programming (XP) módszertan keretében. A „Test-Driven Development: By Example" (2002) című könyvben Beck leírta a TDD öt szabályát, amelyek kanonikussá váltak: írd meg a tesztet a termelési kód előtt, írj pontosan annyi kódot, amennyi a teszt átmentéséhez szükséges, és refaktorálj minden ciklus után.

A TDD kulcs elvei

Az első elv — a teszt határozza meg az interfészt. A fejlesztő kénytelen azon gondolkodni, hogy a komponenst hogyan fogják használni, mielőtt azon gondolkodna, hogyan van implementálva. Ez tiszta API-t alakít ki a kezdetektől fogva.

TDD mint tervezési technika

A második elv — minimális implementáció. Amikor a teszt meg van írva, a fejlesztő pontosan annyi termelési kódot ír, amennyi a teszt átmentéséhez szükséges — egy sorral sem többet. Ez megakadályozza a korai absztrakciót és a túlzott komplexitást, amelyet Martin Fowler Speculative Generalitynek nevez.

A TDD különbsége a szokásos teszteléstől

A legfontosabb különbség a TDD és az „utólagos" tesztelés között — a sorrend fegyelme. A TDD-ben a teszt nem csak ellenőrzi a kódot — irányítja annak szerkezetét. A Microsoft Research (Nagappan et al., 2008) kutatása szerint a TDD-t alkalmazó csapatok 40–90%-kal csökkentik a hibasűrűséget a hagyományos megközelítést használó csapatokhoz képest.

A Red-Green-Refactor ciklus

A Red-Green-Refactor ciklus — egy háromlépéses sorozat, amely minden új tesztnél megismétlődik. Red: írj egy tesztet, amely nem megy át. Green: írj minimális kódot, hogy a teszt átmenjen. Refactor: javítsd a kódot anélkül, hogy megváltoztatnád a viselkedését.

Red fázis: bukó teszt írása

A fejlesztő olyan tesztet ír, amely még nem implementált funkciót ellenőriz. Ebben a szakaszban a tesztnek buknia kell — ez igazolja, hogy a teszt tényleg ellenőriz valamit. Az Android fejlesztési környezetben a JUnit 5 keretrendszer piros jelzést mutat a bukott teszteknél, ami a fázis nevét adta.

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

Green fázis: minimális implementáció

Ebben a szakaszban minimális termelési kódot írnak, amely elegendő a teszt átmentéséhez. Semmi redundancia — csak ami a zöld jelzéshez szükséges. Ha az implementáció lehet konstans — legyen konstans. A refaktorálás a következő lépésben fog megtörténni, amikor új tesztek jelennek meg.

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

Refactor fázis: kockázatmentes javítás

A zöld teszt biztosíték a refaktoráláshoz. A fejlesztő újraírhatja az implementációt, optimalizálhatja a teljesítményt vagy javíthatja az olvashatóságot, biztos abban, hogy a teszt azonnal észleli a várt viselkedéstől való bármilyen eltérést. Az Android mobilfejlesztésben ez a fázis különösen fontos a közös interfészek elkülönítéséhez és a kódduplikáció csökkentéséhez.

A TDD előnyei a mobilfejlesztésben

A TDD alkalmazása mobil projektekben mérhető előnyöket nyújt, amelyeket mind akadémiai kutatások, mind vezető fejlesztőstúdiók gyakorlata igazol.

Hibasűrűség csökkentése

Az IBM (Bhat & Nagappan, 2006) négy ipari projekten végzett kutatása kimutatta, hogy a TDD-t használó csapatok 40%-kal kevesebb hibát követnek el a hagyományosan dolgozó hasonló csapatokhoz képest. A mobilfejlesztésben, ahol a hiba javításának költsége a Google Play-en történő megjelenés után sokkal magasabb, mint a kódírás szakaszában, ez a mutató kritikus.

Kód dokumentálása teszteken keresztül

A TDD szerint írt tesztek az API élő dokumentációjaként szolgálnak. A projektbe érkező fejlesztő elolvashatja a teszteket és megértheti, hogy az egyes komponenseket hogyan kell használni. Ez különösen értékes a magas csapatfluktuáció körülményei között — a mobil stúdiók tipikus problémája.

Magabiztos refaktorálás

A 90% feletti tesztlefedettség lehetővé teszi a fejlesztők számára, hogy félelem nélkül refaktoráljanak. A Google a „Software Engineering at Google" (2020) című könyvében a tesztlefedettséget kulcsfontosságú tényezőnek nevezi, amely lehetővé teszi a kódbázis tisztán tartását milliós kódsorú projektekben.

Eszközök és keretrendszerek a TDD-hez

A TDD ökoszisztéma a mobilfejlesztésben eszközöket foglal magában egységtesztekhez, mockoláshoz és UI-komponensek ellenőrzéséhez — Androidhoz és iOS-hez egyaránt.

Keretrendszer választása Androidhoz

Kotlin Android projektekhez a standard stack tartalmazza a JUnit 5 + MockK kombinációt. A MockK előnyösebb a Mockito-val szemben, mert támogatja a Kotlin elsőosztályú funkcióit — sealed class, korutinok és suspend-függvények további konfiguráció nélkül.

Eszközök iOS-hez

Az iOS fejlesztésben a TDD a XCTesten keresztül valósul meg — az Apple beépített keretrendszere, amely aszerciókat, tesztosztályokat és CI/CD integrációt biztosít az Xcode Server vagy GitHub Actions segítségével. Az iOS mockoláshoz a Cuckoo és OHHTTPStubs könyvtárakat használják.

TDD kódpéldák Kotlinban

Nézzünk egy valós TDD forgatókönyvet Kotlinban Androidhoz — egy felhasználói repository tesztelését. Először megírjuk a tesztet, majd — az implementációt, amely átmegy ezen a teszten.

1. lépés: teszt a UserRepository számára

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

2. lépés: minimális implementáció

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

3. lépés: teszt a gyorsítótárazáshoz offline móddal

Az első teszt átmentése után hozzáadunk egy másodikat — ellenőrizzük a viselkedést hálózati hiba esetén. Most a teszt határozza meg, hogy amikor az API leáll, a repository-nak a gyorsítótárból kell visszaadnia az adatokat.

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

Gyakori hibák a TDD bevezetésekor

A TDD-re való áttérés tipikus hibákkal jár, amelyek semmissé tehetik a módszertan összes előnyét. E csapdák megértése segíti a csapatokat a gyakorlat hatékonyabb bevezetésében.

Túl nagy tesztek

Az első és legelterjedtebb anti-minta — túl nagy funkciómennyiség tesztelése egyetlen tesztben. A tesztnek pontosan egy állítást kell ellenőriznie (egy asszertációt). Ha a teszt megbukik, a fejlesztőnek tudnia kell, hogy pontosan mi romlott el további hibakeresés nélkül.

A piros fázis figyelmen kívül hagyása

A második hiba — olyan teszt írása, amely kezdetben átmegy. Ha a teszt nem volt piros legalább egyszer, nincs bizonyosság, hogy egyáltalán ellenőriz valamit. Szabály: soha ne bízz meg egy olyan tesztben, amelyet nem láttál megbukni.

A refaktorálás kihagyása

A harmadik tipikus hiba — megállás a zöld fázisnál. Refaktorálás nem opcionális, hanem kötelező szakasza a ciklusnak. Nélküle a kódbázis leromlik, a tesztek törékennyé válnak, és a TDD előnyei elvesznek.

• Az implementáció tesztelése, nem a viselkedésé — a tesztek a részletekhez kötődnek és minden refaktoráláskor elromlanak
• A szélső esetek tesztjeinek hiánya — üres listák, null értékek, határfeltételek fedetlenül maradnak
• A tesztek sebességének figyelmen kívül hagyása — lassú tesztek lassítják a visszacsatolási hurkot és megölik a TDD fegyelmet