TDD: cos'è, principi di test e metodologia

Cos'è il TDD?

Il Test-Driven Development è una pratica di sviluppo software in cui i test automatizzati determinano la scrittura del codice di produzione. A differenza dell'approccio tradizionale in cui il codice viene scritto e poi testato, il TDD inverte la sequenza: prima si scrive il test, poi il codice che lo supera.

Il fondatore del TDD è Kent Beck, che ha formulato questa pratica alla fine degli anni '90 nell'ambito della metodologia Extreme Programming (XP). Nel libro “Test-Driven Development: By Example” (2002), Beck ha descritto cinque regole del TDD diventate canoniche: scrivi il test prima del codice di produzione, scrivi esattamente il codice necessario per superare il test e rifattorizza dopo ogni ciclo.

Principi chiave del TDD

Il primo principio — il test definisce l'interfaccia. Lo sviluppatore è costretto a pensare a come il componente verrà utilizzato prima di pensare a come verrà implementato. Questo forma un'API pulita fin dall'inizio.

Il TDD come tecnica di progettazione

Il secondo principio — implementazione minima. Quando il test è scritto, lo sviluppatore scrive esattamente il codice di produzione necessario per superarlo — non una riga in più. Questo previene l'astrazione prematura e la complessità eccessiva, che Martin Fowler chiama Speculative Generality.

Differenza tra TDD e test convenzionale

La differenza chiave tra TDD e test “a posteriori” — la disciplina della sequenza. Nel TDD, il test non solo verifica il codice — ne guida la struttura. Secondo uno studio di Microsoft Research (Nagappan et al., 2008), i team che applicano il TDD dimostrano una riduzione del 40–90% nella densità di difetti rispetto ai team che utilizzano l'approccio tradizionale.

Il ciclo Red-Green-Refactor

Il ciclo Red-Green-Refactor è una sequenza in tre fasi ripetuta per ogni nuovo test. Red: scrivere un test che non supera. Green: scrivere il codice minimo per far superare il test. Refactor: migliorare il codice senza cambiarne il comportamento.

Fase Red: scrivere un test fallimentare

Lo sviluppatore scrive un test che verifica una funzionalità non ancora implementata. In questa fase, il test deve fallire — questo conferma che il test sta effettivamente verificando qualcosa. Nell'ambiente di sviluppo Android, il framework JUnit 5 mostra un indicatore rosso per i test falliti, che ha dato il nome alla fase.

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

Fase Green: implementazione minima

In questa fase, viene scritto il codice di produzione minimo sufficiente per superare il test. Nessuna ridondanza — solo ciò che serve per l'indicatore verde. Se l'implementazione può essere una costante, che sia una costante. Il refactoring avverrà nel passaggio successivo quando appariranno nuovi test.

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

Fase Refactor: miglioramento senza rischio

Il test verde è un'assicurazione per il refactoring. Lo sviluppatore può riscrivere l'implementazione, ottimizzare le prestazioni o migliorare la leggibilità, fiducioso che il test rileverà immediatamente qualsiasi deviazione dal comportamento atteso. Nello sviluppo mobile Android, questa fase è particolarmente importante per estrarre interfacce comuni e ridurre la duplicazione del codice.

Vantaggi del TDD nello sviluppo mobile

L'applicazione del TDD nei progetti mobili offre vantaggi misurabili, confermati sia dalla ricerca accademica che dalla pratica dei principali studi di sviluppo.

Riduzione della densità di difetti

Uno studio IBM (Bhat & Nagappan, 2006) su quattro progetti industriali ha mostrato che i team che utilizzano il TDD producono il 40% in meno di difetti rispetto a team simili che lavorano con lo schema tradizionale. Per lo sviluppo mobile, dove il costo di correzione di un bug dopo il rilascio su Google Play è significativamente più alto rispetto alla fase di scrittura del codice, questa metrica è critica.

Documentazione del codice attraverso i test

I test scritti con il TDD fungono da documentazione vivente dell'API. Uno sviluppatore che entra nel progetto può leggere i test e capire come ogni componente dovrebbe essere utilizzato. Questo è particolarmente prezioso in condizioni di elevato turnover del team — un problema tipico degli studi mobili.

Refactoring sicuro

Una copertura del codice superiore al 90% consente agli sviluppatori di effettuare refactoring senza paura di rompere qualcosa. Google, nel suo libro “Software Engineering at Google” (2020), definisce la copertura dei test un fattore chiave che consente di mantenere pulita la base di codice su progetti con milioni di righe di codice.

Strumenti e framework per il TDD

L'ecosistema TDD nello sviluppo mobile include strumenti per test unitari, mocking e verifica dei componenti dell'interfaccia utente — sia per Android che per iOS.

Scelta del framework per Android

Per i progetti Android in Kotlin, lo stack standard include JUnit 5 + MockK. MockK è preferibile a Mockito perché supporta le funzionalità di prima classe di Kotlin — classi sealed, coroutine e funzioni suspend — senza configurazione aggiuntiva.

Strumenti per iOS

Nello sviluppo iOS, il TDD viene implementato tramite XCTest — il framework integrato di Apple che fornisce asserzioni, classi di test e integrazione CI/CD tramite Xcode Server o GitHub Actions. Per il mocking su iOS vengono utilizzate le librerie Cuckoo e OHHTTPStubs.

Esempi di codice con TDD in Kotlin

Consideriamo uno scenario reale di TDD in Kotlin per Android — il test di un repository utenti. Prima scriviamo il test, poi l'implementazione che lo supera.

Passo 1: test per 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) }
    }
}

Passo 2: implementazione minima

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

Passo 3: test per la cache con modalità offline

Dopo aver superato il primo test, ne aggiungiamo un secondo — verificando il comportamento durante un errore di rete. Ora il test determina che quando l'API fallisce, il repository deve restituire i dati dalla cache.

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

Errori comuni nell'implementazione del TDD

La transizione al TDD comporta errori tipici che possono annullare tutti i vantaggi della metodologia. Comprendere queste insidie aiuta i team ad adottare la pratica in modo più efficace.

Test troppo grandi

Il primo e più comune anti-pattern — testare una quantità troppo grande di funzionalità in un singolo test. Un test dovrebbe verificare esattamente un'asserzione. Se un test fallisce, lo sviluppatore dovrebbe sapere esattamente cosa si è rotto senza ulteriore debugging.

Ignorare la fase rossa

Il secondo errore — scrivere un test che supera fin dall'inizio. Se il test non è mai stato rosso almeno una volta, non c'è certezza che stia effettivamente verificando qualcosa. Regola: non fidarti mai di un test che non hai visto fallire.

Saltare il refactoring

Il terzo errore comune — fermarsi alla fase verde. Il refactoring non è opzionale ma un passaggio obbligatorio del ciclo. Senza di esso, la base di codice si degrada, i test diventano fragili e i vantaggi del TDD si perdono.

• Testare l'implementazione invece del comportamento — i test si legano ai dettagli e si rompono ad ogni refactoring
• Mancanza di test per i casi limite — elenchi vuoti, valori null, condizioni al contorno rimangono scoperti
• Ignorare la velocità dei test — i test lenti rallentano il ciclo di feedback e uccidono la disciplina del TDD