TDD: qué es, principios de prueba y metodología

¿Qué es TDD?

Test-Driven Development es una práctica de desarrollo de software en la que las pruebas automatizadas determinan la escritura del código de producción. A diferencia del enfoque tradicional, donde el código se escribe y luego se prueba, TDD invierte la secuencia: primero se escribe la prueba, luego el código que la pasa.

El fundador de TDD es Kent Beck, quien formuló esta práctica a finales de la década de 1990 como parte de la metodología Extreme Programming (XP). En el libro “Test-Driven Development: By Example” (2002), Beck describió cinco reglas de TDD que se volvieron canónicas: escribe la prueba antes del código de producción, escribe solo el código necesario para pasar la prueba y refactoriza después de cada ciclo.

Principios clave de TDD

El primer principio es que la prueba define la interfaz. El desarrollador se ve obligado a pensar en cómo se usará el componente antes de pensar en cómo se implementa. Esto forma una API limpia desde el principio.

TDD como técnica de diseño

El segundo principio es la implementación mínima. Cuando la prueba está escrita, el desarrollador escribe exactamente el código de producción necesario para que pase, ni una línea más. Esto evita la abstracción prematura y la complejidad excesiva, que Martin Fowler denomina Speculative Generality.

Diferencia entre TDD y las pruebas convencionales

La diferencia clave entre TDD y las pruebas a posteriori es la disciplina de secuencia. En TDD, la prueba no solo verifica el código, sino que guía su estructura. Según un estudio de Microsoft Research (Nagappan et al., 2008), los equipos que aplican TDD muestran una reducción del 40–90% en la densidad de defectos en comparación con los equipos que utilizan el enfoque tradicional.

El ciclo Red-Green-Refactor

El ciclo Red-Green-Refactor es una secuencia de tres pasos que se repite para cada nueva prueba. Red: escribir una prueba que no pasa. Green: escribir el código mínimo para que la prueba pase. Refactor: mejorar el código sin cambiar su comportamiento.

Fase Red: escribir una prueba fallida

El desarrollador escribe una prueba que verifica una funcionalidad aún no implementada. En esta etapa, la prueba debe fallar, lo que confirma que la prueba realmente verifica algo. En el entorno de desarrollo de Android, el framework JUnit 5 muestra un indicador rojo para las pruebas fallidas, lo que dio nombre a la fase.

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

Fase Green: implementación mínima

En esta etapa se escribe el código de producción mínimo suficiente para que la prueba pase. Sin redundancia, solo lo necesario para el indicador verde. Si la implementación puede ser una constante, que sea una constante. La refactorización ocurrirá en el siguiente paso cuando aparezcan nuevas pruebas.

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

Fase Refactor: mejora sin riesgo

La prueba verde es un seguro para la refactorización. El desarrollador puede reescribir la implementación, optimizar el rendimiento o mejorar la legibilidad, con la confianza de que la prueba detectará de inmediato cualquier desviación del comportamiento esperado. En el desarrollo móvil Android, esta fase es especialmente importante para extraer interfaces comunes y reducir la duplicación de código.

Beneficios de TDD en el desarrollo móvil

La aplicación de TDD en proyectos móviles ofrece beneficios medibles, confirmados tanto por la investigación académica como por la práctica de los principales estudios de desarrollo.

Reducción de la densidad de defectos

Un estudio de IBM (Bhat & Nagappan, 2006) en cuatro proyectos industriales mostró que los equipos que usan TDD producen un 40% menos de defectos en comparación con equipos similares que trabajan con el enfoque tradicional. Para el desarrollo móvil, donde el costo de corregir un error después del lanzamiento en Google Play es significativamente mayor que en la etapa de escritura del código, esta métrica es crítica.

Documentación del código a través de pruebas

Las pruebas escritas con TDD sirven como documentación viva de la API. Un desarrollador que se incorpora al proyecto puede leer las pruebas y entender cómo debe usarse cada componente. Esto es especialmente valioso en situaciones de alta rotación del equipo, un desafío típico de los estudios móviles.

Refactorización segura

Una cobertura de código que supera el 90% permite a los desarrolladores refactorizar sin miedo a romper algo. Google, en su libro “Software Engineering at Google” (2020), califica la cobertura de pruebas como un factor clave para mantener la base de código limpia en proyectos con millones de líneas de código.

Herramientas y frameworks para TDD

El ecosistema de TDD en el desarrollo móvil incluye herramientas para pruebas unitarias, mocking y verificación de componentes de UI, tanto para Android como para iOS.

Cómo elegir un framework para Android

Para proyectos Android con Kotlin, el stack estándar incluye JUnit 5 + MockK. MockK es preferible a Mockito porque admite características de primera clase de Kotlin (clases selladas, corrutinas y funciones suspend) sin configuración adicional.

Herramientas para iOS

En el desarrollo iOS, TDD se implementa a través de XCTest, el framework integrado de Apple que proporciona aserciones, clases de prueba e integración con CI/CD mediante Xcode Server o GitHub Actions. Para mocking en iOS se utilizan librerías como Cuckoo y OHHTTPStubs.

Ejemplos de código con TDD en Kotlin

Veamos un escenario real de TDD en Kotlin para Android: pruebas de un repositorio de usuarios. Primero escribimos la prueba, luego la implementación que la supera.

Paso 1: prueba para 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) }
    }
}

Paso 2: implementación mínima

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

Paso 3: prueba de caché con modo sin conexión

Después de superar la primera prueba, añadimos una segunda que verifica el comportamiento durante un error de red. Ahora la prueba determina que cuando la API falla, el repositorio debe devolver datos de la caché.

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

Errores comunes al implementar TDD

La transición a TDD conlleva errores típicos que pueden anular todos los beneficios de la metodología. Comprender estos errores ayuda a los equipos a adoptar la práctica de manera más efectiva.

Pruebas demasiado grandes

El primer y más común antipatrón es probar demasiada funcionalidad en una sola prueba. Una prueba debe verificar exactamente una afirmación. Si una prueba falla, el desarrollador debe saber exactamente qué se rompió sin necesidad de depuración adicional.

Ignorar la fase roja

El segundo error es escribir una prueba que pasa desde el principio. Si la prueba nunca fue roja al menos una vez, no hay certeza de que realmente verifique algo. Regla: nunca confíes en una prueba que no hayas visto fallar.

Omitir la refactorización

El tercer error común es detenerse en la fase verde. La refactorización no es opcional, sino un paso obligatorio del ciclo. Sin ella, la base de código se degrada, las pruebas se vuelven frágiles y se pierden los beneficios de TDD.

• Probar la implementación en lugar del comportamiento: las pruebas se vinculan a los detalles y se rompen con cada refactorización
• Falta de pruebas para casos límite: listas vacías, valores nulos, condiciones frontera quedan sin cubrir
• Ignorar la velocidad de las pruebas: las pruebas lentas ralentizan el ciclo de retroalimentación y destruyen la disciplina de TDD