TDD en Java desde cero: cómo las pruebas cambian el código y salvan los nervios

Por qué TDD no se trata de "escribir pruebas", sino de "pensar de otra manera"

Imagine que está construyendo una casa. Tiene planos, materiales y un equipo. Pero empieza a colocar ladrillos sin haber revisado los cimientos. Un mes después, descubre que las paredes tienen grietas. ¿Le suena familiar? En programación, esto se llama "lo arreglamos después". Y ese "después" suele llegar a las 3 de la mañana antes del despliegue.

El desarrollo guiado por pruebas (TDD — Test-Driven Development) es una técnica que pone el proceso patas arriba. No escribe código y luego pruebas. Primero escribe la prueba, y solo después el código que pasa esa prueba. ¿Suena una locura? En la práctica, ahorra horas, nervios y hace que el código sea más limpio que el aire de la mañana en la montaña.

En este artículo, analizaremos TDD en Java con ejemplos concretos. Sin rodeos: solo código, el ciclo Red-Green-Refactor y escenarios reales. ¡Allá vamos!

¿Qué es TDD y cómo funciona el ciclo Red-Green-Refactor?

TDD se basa en tres pasos simples que se repiten cíclicamente:

\n
• Red — escribimos una prueba que no pasa (debe fallar).
\n
• Green — escribimos el código mínimo para que la prueba pase.
\n
• Refactor — mejoramos el código sin cambiar su comportamiento. Las pruebas permanecen en verde.
\n

Parece que esto ralentiza el desarrollo. En realidad, lo acelera. Deja de preguntarse "¿esto funciona?". Usted lo sabe: funciona, porque la prueba está en verde.

Principios principales de TDD

\n
• No escriba ni una línea de código de producción sin una prueba.
\n
• La prueba debe ser lo más simple posible y verificar exactamente un comportamiento.
\n
• El código se escribe solo lo suficiente para que la prueba pase. Nada de "y ya que estamos, agreguemos esto por si acaso".
\n

Ahora pasemos a Java y JUnit 5, el framework más popular para pruebas unitarias.

Configuración del proyecto: Maven, JUnit 5 y estructura

Para los ejemplos, usaremos Maven. Agregue la dependencia en pom.xml:

<dependency>\n    <groupId>org.junit.jupiter</groupId>\n    <artifactId>junit-jupiter-api</artifactId>\n    <version>5.10.0</version>\n    <scope>test</scope>\n</dependency>

La estructura de carpetas es estándar para Maven:

src/\n  main/java/com/example/\n  test/java/com/example/

Todas las clases de prueba se colocan en src/test/java. El nombre de la clase de prueba generalmente coincide con el nombre de la clase que se prueba + el sufijo Test. Por ejemplo, Calculator → CalculatorTest.

Primer ciclo TDD: escribimos una calculadora desde cero

Tarea: crear el método add(int a, int b) que devuelva la suma. Con TDD, comenzamos no con la clase, sino con la prueba.

Paso 1: Red — escribimos una prueba que fallará

import org.junit.jupiter.api.Test;\nimport static org.junit.jupiter.api.Assertions.*;\n\npublic class CalculatorTest {\n\n    @Test\n    void shouldAddTwoNumbers() {\n        Calculator calc = new Calculator();\n        int result = calc.add(2, 3);\n        assertEquals(5, result);\n    }\n}

Intentamos ejecutarlo: el compilador se queja: la clase Calculator no existe. Excelente, la luz roja está encendida.

Paso 2: Green — escribimos el código mínimo

Creamos la clase Calculator con un método que simplemente devuelve la suma:

public class Calculator {\n    public int add(int a, int b) {\n        return a + b;\n    }\n}

Ejecutamos la prueba — verde. La implementación mínima posible funcionó.

Paso 3: Refactor

En esta etapa, el código ya es simple, no hay nada que refactorizar. Pero imaginemos que queremos renombrar el método o agregar una verificación de desbordamiento. Lo hacemos, y la prueba sigue pasando. Si algo se rompe, la prueba fallará e indicará inmediatamente el problema.

Compl