Desarrollo Guiado por Pruebas

El Desarrollo Guiado por Pruebas es simple de describir y difícil de dominar:

1. Rojo: Escribe una prueba que falle para la siguiente pequeña pieza de funcionalidad
2. Verde: Escribe el código mínimo para hacer que la prueba pase
3. Refactorizar: Limpia el código mientras mantienes las pruebas en verde

Eso es todo. Tres pasos, repetidos cientos de veces al día.

El orden importa. Escribes la prueba primero, antes de que exista cualquier código de producción. Esto se siente al revés al principio. Pero lo cambia todo:

• Piensas en cómo se usará el código antes de cómo se implementará
• Obtienes retroalimentación inmediata sobre si tu código funciona
• Construyes una red de seguridad que permite cambios sin miedo
• Creas documentación ejecutable de lo que hace el código

La parte más difícil de TDD es aprender a escribir pruebas para código que aún no existe. Así es como:

Comienza con la interfaz, no con la implementación. ¿Cómo debería verse el código cuando esté terminado? Escribe una prueba que lo use de esa manera.

Comienza pequeño. No intentes probar todo a la vez. Prueba primero el caso más simple posible.

Haz que falle por la razón correcta. La prueba debería fallar porque la funcionalidad no existe, no porque cometiste un error de sintaxis.

Usa nombres de prueba como documentación. El nombre de la prueba debe describir qué comportamiento estás probando: "devuelve lista vacía cuando ningún elemento coincide con el filtro" no "prueba1."

Escribir la prueba primero te obliga a pensar en:

• ¿Qué entradas necesita este código?
• ¿Qué salidas debería producir?
• ¿Qué sucede en casos extremos?
• ¿Cómo llamará otro código a esto?

Estas son preguntas de diseño. Al responderlas antes de escribir el código, tomas mejores decisiones de diseño.

Una vez que tienes una prueba que falla, hazla pasar. Pero aquí está la disciplina: escribe el código mínimo para pasar la prueba, nada más.

Esto significa:

• Si una constante hace que la prueba pase, usa una constante
• Si codificar un valor de retorno funciona, codifícalo
• No generalices hasta que tengas pruebas que requieran generalización

Esto suena ridículo. "¿Solo devolver 5?" Sí, si eso hace que la prueba pase. Luego escribe otra prueba que te obligue a hacer un cálculo real.

¿Por qué? Porque:

• Construyes funcionalidad en pasos pequeños y verificados
• Nunca escribes código que no necesitas
• Descubres el diseño de manera incremental
• Cada línea de código está justificada por una prueba

La magia sucede cuando triangulas. Primera prueba: devolver 5. Segunda prueba (entrada diferente): ahora tienes que calcular. Tercera prueba: ahora tienes que manejar casos extremos. Cada prueba te empuja hacia una implementación real.

Después de que la prueba pasa, limpia. Esto no es opcional.

El paso de refactorización es donde:

• Eliminas duplicación (DRY: No Te Repitas)
• Mejoras nombres (haz que el código se lea como prosa)
• Simplificas lógica (reduce la carga cognitiva)
• Reorganizas (mueve el código a donde pertenece)

La clave: mantén las pruebas pasando durante todo el proceso. Refactoriza en pasos pequeños, ejecutando pruebas después de cada cambio. Si las pruebas fallan, sabes exactamente qué se rompió.

Aquí es donde TDD vale la pena. Sin pruebas, refactorizar es aterrador—podrías romper algo. Con pruebas, refactorizar es rutinario—sabrás inmediatamente si rompes algo.

Saltarse el paso de refactorización lleva a lo que Kent Beck llama "excusas de verde rápido." El código funciona, pero está desordenado. El desorden se acumula. Pronto la base de código es difícil de trabajar, y has perdido el beneficio de TDD.

Mito: TDD es más lento. Realidad: TDD parece más lento al principio porque estás escribiendo más código. Pero pasas menos tiempo depurando, menos tiempo en el depurador, menos tiempo arreglando errores de producción. Durante la vida de la base de código, TDD es más rápido.

Mito: TDD lleva a sobre-probar. Realidad: TDD lleva exactamente a las pruebas que necesitas—ni más, ni menos. Pruebas lo que construyes. Probar después a menudo lleva a pruebas faltantes (olvidas casos extremos) o pruebas redundantes (pruebas lo mismo de múltiples maneras).

Mito: TDD no funciona para [mi dominio]. Realidad: TDD funciona para cualquier código que pueda ser probado. Si tu código no puede ser probado, eso es un problema de diseño. TDD te obliga a escribir código que se puede probar, que es mejor código.

Mito: No tenemos tiempo para TDD. Realidad: No tienes tiempo para no hacerlo. Los errores son costosos. Depurar es costoso. Los incidentes de producción son costosos. TDD es una inversión que vale la pena.