TDD: vad är det, testprinciper och metodologi

Vad är TDD?

Test-Driven Development — är en mjukvaruutvecklingspraxis där automatiserade tester bestämmer skrivningen av produktionskod. Till skillnad från det traditionella tillvägagångssättet, där koden först skrivs och sedan testas, vänder TDD på ordningen: först skrivs testet, sedan koden som klarar detta test.

Grundaren av TDD anses vara Kent Beck, som formulerade denna praxis i slutet av 1990-talet inom ramen för metodologin Extreme Programming (XP). I boken ”Test-Driven Development: By Example” (2002) beskrev Beck fem regler för TDD som har blivit kanoniska: skriv testet före produktionskoden, skriv precis så mycket kod som behövs för att klara testet och refaktorisera efter varje cykel.

Nyckelprinciper för TDD

Den första principen — testet definierar gränssnittet. Utvecklaren tvingas tänka på hur komponenten kommer att användas innan han tänker på hur den är implementerad. Detta formar ett rent API från början.

TDD som designteknik

Den andra principen — minimal implementering. När testet är skrivet skriver utvecklaren precis så mycket produktionskod som behövs för att klara det — inte en rad mer. Detta förhindrar för tidig abstraktion och överdriven komplexitet som Martin Fowler kallar Speculative Generality.

Skillnad mellan TDD och vanlig testning

Den viktigaste skillnaden mellan TDD och testning ”i efterhand” — disciplin i ordningsföljd. I TDD kontrollerar testet inte bara koden — det styr dess struktur. Enligt forskning från Microsoft Research (Nagappan et al., 2008) uppvisar team som tillämpar TDD en minskning av defekttätheten med 40–90% jämfört med team som använder traditionellt tillvägagångssätt.

Red-Green-Refactor-cykeln

Red-Green-Refactor-cykeln — är en trestegssekvens som upprepas för varje nytt test. Red: skriv ett test som inte klarar sig. Green: skriv minimal kod för att klara testet. Refactor: förbättra koden utan att ändra dess beteende.

Fas Red: skriva ett misslyckat test

Utvecklaren skriver ett test som kontrollerar ännu inte implementerad funktionalitet. I denna fas måste testet misslyckas — detta bekräftar att testet verkligen kontrollerar något. I Android-utvecklingsmiljön visar JUnit 5-ramverket röd indikation för misslyckade test, vilket gav fasen dess namn.

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

Fas Green: minimal implementering

I denna fas skrivs minimal produktionskod som är tillräcklig för att klara testet. Ingen redundans — bara vad som behövs för grön indikation. Om implementeringen kan vara en konstant — låt den vara en konstant. Refaktorisering kommer att ske i nästa steg när nya test dyker upp.

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

Fas Refactor: förbättring utan risk

Det gröna testet är en försäkring för refaktorisering. Utvecklaren kan skriva om implementeringen, optimera prestanda eller förbättra läsbarheten, med vetskapen att testet omedelbart kommer att upptäcka varje avvikelse från det förväntade beteendet. I mobil utveckling på Android är denna fas särskilt viktig för att separera gemensamma gränssnitt och minska kodduplicering.

Fördelar med TDD inom mobil utveckling

Tillämpning av TDD i mobila projekt ger mätbara fördelar, bekräftade av både akademisk forskning och praktiken hos ledande utvecklingsstudior.

Minskning av defekttäthet

IBM:s forskning (Bhat & Nagappan, 2006) på fyra industriprojekt visade att team som använder TDD gör 40% färre defekter jämfört med liknande team som arbetar traditionellt. För mobil utveckling, där kostnaden för att åtgärda en bugg efter lansering i Google Play är betydligt högre än i kodskrivningsfasen, är denna metrik kritisk.

Dokumentation av kod genom test

Test skrivna enligt TDD fungerar som levande dokumentation av API:et. En utvecklare som kommer in i projektet kan läsa testerna och förstå hur varje komponent ska användas. Detta är särskilt värdefullt under förhållanden med hög personalomsättning — ett typiskt problem för mobila studior.

Trygg refaktorisering

Kodtäckning som överstiger 90% gör att utvecklare kan utföra refaktorisering utan rädsla för att bryta något. Google kallar i sin bok ”Software Engineering at Google” (2020) testtäckning för den viktigaste faktorn som gör det möjligt att hålla kodbasen ren i projekt med miljontals rader kod.

Verktyg och ramverk för TDD

TDD-ekosystemet inom mobil utveckling omfattar verktyg för enhetstester, mockning och kontroll av UI-komponenter — både för Android och iOS.

Välja ramverk för Android

För Android-projekt i Kotlin innehåller standardstacken JUnit 5 + MockK. MockK är att föredra framför Mockito eftersom det stöder Kotlin-funktioner av första klass — sealed class, korutiner och suspend-funktioner utan extra konfiguration.

Verktyg för iOS

I iOS-utveckling implementeras TDD genom XCTest — Apples inbyggda ramverk som tillhandahåller påståenden, testklasser och integration med CI/CD via Xcode Server eller GitHub Actions. För mockning på iOS används biblioteken Cuckoo och OHHTTPStubs.

Kodexempel på TDD i Kotlin

Låt oss titta på ett verkligt TDD-scenario i Kotlin för Android — testning av en användarresurs. Först skriver vi testet, sedan — implementeringen som klarar detta test.

Steg 1: test för 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) }
    }
}

Steg 2: minimal implementering

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

Steg 3: test för cachning med offlineläge

Efter att ha klarat det första testet lägger vi till ett andra — vi kontrollerar beteendet vid nätverksfel. Nu bestämmer testet att när API:et misslyckas ska resursen returnera data från cachen.

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

Vanliga misstag vid införande av TDD

Övergången till TDD åtföljs av typiska misstag som kan omintetgöra alla fördelar med metodologin. Att förstå dessa fallgropar hjälper team att implementera praktiken mer effektivt.

För stora test

Det första och vanligaste anti-mönstret — testning av för stor mängd funktionalitet i ett enda test. Ett test ska kontrollera exakt ett påstående (en assertion). Om ett test misslyckas måste utvecklaren veta exakt vad som gick sönder utan ytterligare felsökning.

Ignorera den röda fasen

Det andra misstaget — att skriva ett test som klarar sig från början. Om ett test inte har varit rött minst en gång finns det ingen säkerhet att det överhuvudtaget kontrollerar något. Regel: lita aldrig på ett test som du inte har sett misslyckas.

Hoppa över refaktorisering

Det tredje typiska misstaget — att stanna i den gröna fasen. Refaktorisering är inte en valfri, utan en obligatorisk fas i cykeln. Utan den försämras kodbasen, test blir sköra och fördelarna med TDD går förlorade.

• Testning av implementering, inte beteende — test binds till detaljer och bryts vid varje refaktorisering
• Avsaknad av test för gränsfall — tomma listor, null-värden, gränsvillkor förblir otäckta
• Ignorera testhastighet — långsamma test saktar ner återkopplingsslingan och dödar TDD-disciplinen