TDD: wat is het, testprincipes en methodologie

Wat is TDD?

Test-Driven Development — is een softwareontwikkelingspraktijk waarbij geautomatiseerde tests het schrijven van productiecode bepalen. In tegenstelling tot de traditionele benadering, waarbij code wordt geschreven en vervolgens getest, keert TDD de volgorde om: eerst wordt de test geschreven, dan de code die deze test doorstaat.

De grondlegger van TDD is Kent Beck, die deze praktijk aan het einde van de jaren 1990 formuleerde binnen de methodologie Extreme Programming (XP). In het boek „Test-Driven Development: By Example" (2002) beschreef Beck vijf regels van TDD die canoniek zijn geworden: schrijf de test vóór de productiecode, schrijf precies zoveel code als nodig is om de test te laten slagen en refactor na elke cyclus.

Belangrijkste principes van TDD

Het eerste principe — de test bepaalt de interface. De ontwikkelaar wordt gedwongen na te denken over hoe het component zal worden gebruikt voordat hij nadenkt over hoe het is geïmplementeerd. Dit vormt vanaf het begin een schone API.

TDD als ontwerptechniek

Het tweede principe — minimale implementatie. Wanneer de test is geschreven, schrijft de ontwikkelaar precies zoveel productiecode als nodig is om hem te laten slagen — geen regel meer. Dit voorkomt voortijdige abstractie en overmatige complexiteit, die Martin Fowler Speculative Generality noemt.

Verschil tussen TDD en gewoon testen

Het belangrijkste verschil tussen TDD en testen „achteraf" — volgordediscipline. In TDD controleert de test niet alleen de code — hij stuurt de structuur ervan. Volgens onderzoek van Microsoft Research (Nagappan et al., 2008) vertonen teams die TDD toepassen een vermindering van de defectdichtheid met 40–90% in vergelijking met teams die de traditionele benadering gebruiken.

De Red-Green-Refactor-cyclus

De Red-Green-Refactor-cyclus — is een driestapsreeks die voor elke nieuwe test wordt herhaald. Red: schrijf een test die niet slaagt. Green: schrijf minimale code om de test te laten slagen. Refactor: verbeter de code zonder het gedrag te veranderen.

Fase Red: het schrijven van een falende test

De ontwikkelaar schrijft een test die nog niet geïmplementeerde functionaliteit controleert. In deze fase moet de test falen — dit bevestigt dat de test echt iets controleert. In de Android-ontwikkelomgeving toont het JUnit 5-framework een rode indicatie voor falende tests, wat de fase zijn naam heeft gegeven.

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

Fase Green: minimale implementatie

In deze fase wordt minimale productiecode geschreven die voldoende is om de test te laten slagen. Geen redundantie — alleen wat nodig is voor de groene indicatie. Als de implementatie een constante kan zijn — laat het een constante zijn. Refactoring zal in de volgende stap plaatsvinden wanneer nieuwe tests verschijnen.

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

Fase Refactor: verbeteren zonder risico

De groene test is een verzekering voor refactoring. De ontwikkelaar kan de implementatie herschrijven, de prestaties optimaliseren of de leesbaarheid verbeteren, in de wetenschap dat de test onmiddellijk elke afwijking van het verwachte gedrag zal detecteren. In mobiele ontwikkeling op Android is deze fase vooral belangrijk voor het scheiden van gemeenschappelijke interfaces en het verminderen van codeduplicatie.

Voordelen van TDD in mobiele ontwikkeling

Het toepassen van TDD in mobiele projecten levert meetbare voordelen op, bevestigd door zowel academisch onderzoek als de praktijk van toonaangevende ontwikkelingsstudio's.

Vermindering van defectdichtheid

Onderzoek van IBM (Bhat & Nagappan, 2006) op vier industriële projecten toonde aan dat teams die TDD gebruiken 40% minder defecten maken in vergelijking met vergelijkbare teams die traditioneel werken. Voor mobiele ontwikkeling, waar de kosten van het repareren van een bug na release in Google Play aanzienlijk hoger zijn dan in de schrijffase van code, is deze metric cruciaal.

Documentatie van code door tests

Tests geschreven volgens TDD dienen als levende documentatie van de API. Een ontwikkelaar die in het project komt, kan de tests lezen en begrijpen hoe elk component moet worden gebruikt. Dit is vooral waardevol in situaties van hoge teamverloop — een typisch probleem van mobiele studio's.

Zelfverzekerde refactoring

Code dekking door tests die 90% overschrijdt, stelt ontwikkelaars in staat om refactoring uit te voeren zonder angst om iets te breken. Google noemt in zijn boek „Software Engineering at Google" (2020) testdekking de belangrijkste factor die het mogelijk maakt de codebase schoon te houden in projecten met miljoenen regels code.

Tools en frameworks voor TDD

Het TDD-ecosysteem in mobiele ontwikkeling omvat tools voor unittesten, mocking en controle van UI-componenten — zowel voor Android als iOS.

Frameworks kiezen voor Android

Voor Android-projecten in Kotlin omvat de standaard stack JUnit 5 + MockK. MockK heeft de voorkeur boven Mockito omdat het Kotlin first-class functions ondersteunt — sealed class, coroutines en suspend-functies zonder extra configuratie.

Tools voor iOS

In iOS-ontwikkeling wordt TDD geïmplementeerd via XCTest — het ingebouwde Apple-framework dat assertions, testklassen en integratie met CI/CD via Xcode Server of GitHub Actions biedt. Voor mocking op iOS worden de bibliotheken Cuckoo en OHHTTPStubs gebruikt.

Codevoorbeelden van TDD in Kotlin

Laten we een realistisch TDD-scenario in Kotlin voor Android bekijken — het testen van een gebruikersrepository. Eerst schrijven we de test, dan — de implementatie die deze test doorstaat.

Stap 1: test voor 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) }
    }
}

Stap 2: minimale implementatie

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

Stap 3: test voor caching met offline modus

Na het doorstaan van de eerste test voegen we een tweede toe — we controleren het gedrag bij een netwerkfout. Nu bepaalt de test dat bij een API-storing de repository gegevens uit de cache moet retourneren.

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

Veelvoorkomende fouten bij het implementeren van TDD

De overgang naar TDD gaat gepaard met typische fouten die alle voordelen van de methodologie teniet kunnen doen. Inzicht in deze valkuilen helpt teams de praktijk effectiever te implementeren.

Te grote tests

Het eerste en meest voorkomende anti-patroon — het testen van een te grote hoeveelheid functionaliteit in één test. Een test moet precies één bewering controleren (één assertion). Als een test faalt, moet de ontwikkelaar weten wat er precies is gebroken zonder extra debugging.

Negeren van de rode fase

De tweede fout — het schrijven van een test die vanaf het begin slaagt. Als een test niet minstens één keer rood is geweest, is er geen zekerheid dat hij überhaupt iets controleert. Regel: vertrouw nooit een test die je niet hebt zien falen.

Overslaan van refactoring

De derde typische fout — stoppen in de groene fase. Refactoring is geen optionele, maar een verplichte fase van de cyclus. Zonder dit degradeert de codebase, worden tests breekbaar en gaan de voordelen van TDD verloren.

• Testen van implementatie, niet van gedrag — tests worden gekoppeld aan details en breken bij elke refactoring
• Ontbreken van tests voor randgevallen — lege lijsten, null-waarden, randvoorwaarden blijven ongedekt
• Negeren van testsnelheid — trage tests vertragen de feedbacklus en doden de TDD-discipline