TDD: ce este, principii de testare și metodologie

Ce este TDD?

Test-Driven Development — este o practică de dezvoltare software în care testele automate determină scrierea codului de producție. Spre deosebire de abordarea tradițională, unde codul se scrie și apoi se testează, TDD inversează ordinea: mai întâi se scrie testul, apoi codul care trece acest test.

Fondatorul TDD este considerat Kent Beck, care a formulat această practică la sfârșitul anilor 1990 în cadrul metodologiei Extreme Programming (XP). În cartea „Test-Driven Development: By Example" (2002) Beck a descris cinci reguli TDD care au devenit canonice: scrie testul înaintea codului de producție, scrie exact atât cod cât este necesar pentru a trece testul și refactorizează după fiecare ciclu.

Principiile cheie ale TDD

Primul principiu — testul definește interfața. Dezvoltatorul este forțat să se gândească la modul în care componentul va fi utilizat înainte de a se gândi la modul în care este implementat. Acest lucru formează un API curat de la bun început.

TDD ca tehnică de proiectare

Al doilea principiu — implementare minimă. Când testul este scris, dezvoltatorul scrie exact atâta cod de producție cât este necesar pentru a-l trece — nici o linie în plus. Acest lucru previne abstractizarea prematură și complexitatea excesivă pe care Martin Fowler o numește Speculative Generality.

Diferența dintre TDD și testarea obișnuită

Diferența cheie între TDD și testarea „post factum" — disciplina secvenței. În TDD, testul nu doar verifică codul — ci îi ghidează structura. Potrivit cercetării Microsoft Research (Nagappan et al., 2008), echipele care aplică TDD demonstrează o reducere a densității defectelor cu 40–90% comparativ cu echipele care folosesc abordarea tradițională.

Ciclul Red-Green-Refactor

Ciclul Red-Green-Refactor — este o secvență în trei pași repetată pentru fiecare test nou. Red: scrie un test care nu trece. Green: scrie codul minim pentru ca testul să treacă. Refactor: îmbunătățește codul fără a-i schimba comportamentul.

Faza Red: scrierea testului eșuat

Dezvoltatorul scrie un test care verifică o funcționalitate neimplementată încă. În această fază testul trebuie să eșueze — aceasta confirmă că testul chiar verifică ceva. În mediul de dezvoltare Android, frameworkul JUnit 5 arată indicația roșie pentru testele eșuate, ceea ce a dat numele fazei.

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

Faza Green: implementare minimă

În această fază se scrie codul de producție minim suficient pentru a trece testul. Nici o redundanță — doar ceea ce este necesar pentru indicația verde. Dacă implementarea poate fi o constantă — să fie o constantă. Refactorizarea va avea loc la pasul următor când apar noi teste.

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

Faza Refactor: îmbunătățire fără risc

Testul verde este asigurarea pentru refactorizare. Dezvoltatorul poate rescrie implementarea, optimiza performanța sau îmbunătăți lizibilitatea, fiind sigur că testul va detecta imediat orice abatere de la comportamentul așteptat. În dezvoltarea mobilă pe Android, această fază este deosebit de importantă pentru extragerea interfețelor comune și reducerea duplicării codului.

Avantajele TDD în dezvoltarea mobilă

Aplicarea TDD în proiectele mobile oferă avantaje măsurabile, confirmate atât de cercetările academice, cât și de practica studiourilor de dezvoltare de top.

Reducerea densității defectelor

Cercetarea IBM (Bhat & Nagappan, 2006) pe patru proiecte industriale a arătat că echipele care folosesc TDD comit cu 40% mai puține defecte comparativ cu echipele similare care lucrează tradițional. Pentru dezvoltarea mobilă, unde costul remedierii unui bug după lansarea în Google Play este semnificativ mai mare decât în faza de scriere a codului, această metrică este critică.

Documentarea codului prin teste

Testele scrise conform TDD servesc ca documentație vie a API-ului. Dezvoltatorul care vine în proiect poate citi testele și înțelege cum trebuie utilizat fiecare component. Acest lucru este deosebit de valoros în condiții de fluctuație ridicată a echipei — o problemă tipică a studiourilor mobile.

Refactorizare încrezătoare

Acoperirea codului cu teste ce depășește 90% permite dezvoltatorilor să efectueze refactorizări fără teama de a strica ceva. Google în cartea sa „Software Engineering at Google" (2020) numește acoperirea cu teste factorul cheie care permite menținerea bazei de cod curată în proiecte cu milioane de linii de cod.

Instrumente și frameworkuri pentru TDD

Ecosistemul TDD în dezvoltarea mobilă include instrumente pentru teste unitare, mocking și verificarea componentelor UI — atât pentru Android, cât și pentru iOS.

Alegerea frameworkului pentru Android

Pentru proiectele Android pe Kotlin, stiva standard include JUnit 5 + MockK. MockK este preferat față de Mockito deoarece suportă funcțiile Kotlin de primă clasă — sealed class, corutini și suspend-funcții fără configurare suplimentară.

Instrumente pentru iOS

În dezvoltarea iOS, TDD se implementează prin XCTest — frameworkul încorporat Apple care oferă aserțiuni, clase de test și integrare cu CI/CD prin Xcode Server sau GitHub Actions. Pentru mocking pe iOS se folosesc bibliotecile Cuckoo și OHHTTPStubs.

Exemple de cod TDD în Kotlin

Să analizăm un scenariu real TDD în Kotlin pentru Android — testarea unui repository de utilizatori. Mai întâi scriem testul, apoi — implementarea care trece acest test.

Pasul 1: test pentru 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) }
    }
}

Pasul 2: implementare minimă

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

Pasul 3: test pentru cache cu mod offline

După trecerea primului test, adăugăm al doilea — verificăm comportamentul la eroare de rețea. Acum testul stabilește că la căderea API-ului, repositoryul trebuie să returneze datele din 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)
}

Greșeli tipice la implementarea TDD

Tranziția la TDD este însoțită de greșeli tipice care pot anula toate avantajele metodologiei. Înțelegerea acestor capcane ajută echipele să implementeze practica mai eficient.

Teste prea mari

Primul și cel mai răspândit anti-pattern — testarea unui volum prea mare de funcționalitate într-un singur test. Testul trebuie să verifice exact o afirmație (o singură aserțiune). Dacă testul eșuează, dezvoltatorul trebuie să știe exact ce s-a stricat fără debugging suplimentar.

Ignorarea fazei roșii

A doua greșeală — scrierea unui test care trece de la început. Dacă testul nu a fost roșu măcar o dată, nu există certitudinea că verifică ceva. Regula: nu avea încredere niciodată într-un test pe care nu l-ai văzut eșuând.

Omiterea refactorizării

A treia greșeală tipică — oprirea la faza verde. Refactorizarea nu este o etapă opțională, ci obligatorie a ciclului. Fără ea, baza de cod degradează, testele devin fragile și avantajele TDD se pierd.

• Testarea implementării, nu a comportamentului — testele se leagă de detalii și se strică la fiecare refactorizare
• Lipsa testelor pentru cazuri marginale — liste goale, valori null, condiții limită rămân neacoperite
• Ignorarea vitezei testelor — testele lente încetinesc bucla de feedback și ucid disciplina TDD