Desarrollo guiado por pruebas.
Una disciplina de desarrollo en la que escribes una prueba que falla antes que el código que la hace pasar y, a continuación, refactorizas, dejando que las pruebas guíen el diseño en ciclos cortos y ajustados.
##Intent
Guiar el diseño y verificar la corrección del código escribiendo una prueba que falle para cada pequeña porción de comportamiento antes de escribir el código que la satisface, y mejorando después el diseño mientras las pruebas te mantienen a salvo.
##Problem
El código escrito sin pruebas es arriesgado de cambiar: no hay una forma rápida de saber si una modificación rompió algo. Las pruebas escritas a posteriori tienden a ser superficiales, moldeadas para encajar con un código que quizá ya sea difícil de probar, y rara vez influyen en el diseño.
Sin una función forzante, los diseños también tienden a enredarse y a volverse difíciles de ejercitar de forma aislada.
##Solution
Trabaja en un ciclo corto Rojo-Verde-Refactorizar:
- Rojo: escribe una pequeña prueba para el siguiente fragmento de comportamiento y mírala fallar.
- Verde: escribe el código más simple que hace pasar la prueba, aunque sea feo.
- Refactorizar: limpia el código (y las pruebas) ahora que están en verde, con la suite protegiéndote frente a regresiones.
Repite en bucles de pocos minutos. Como las pruebas van primero, el código es testeable por construcción y la suite documenta el comportamiento previsto.
##Structure
- El ciclo: Rojo → Verde → Refactorizar, repetido de forma continua.
- Lista de pruebas: la lista en curso de comportamientos que aún faltan por cubrir.
- Arrange–Act–Assert (Preparar–Actuar–Afirmar): la forma de una prueba unitaria enfocada.
- Unidad bajo prueba: la pequeña porción de comportamiento que fija cada prueba.
##Applicability
- Úsalo para código con lógica y ramificación reales, y para código de larga vida que cambiará a menudo.
- Especialmente valioso allí donde importan un ciclo de retroalimentación rápido y la seguridad frente a regresiones.
- Menos adecuado para experimentos desechables (spikes) o trabajo de UI exploratorio donde el diseño aún está en flujo.
##How to Implement
- Elige el siguiente comportamiento pequeño de tu lista de pruebas.
- Escribe una prueba que lo afirme y ejecuta la suite para verla fallar (rojo).
- Escribe el código mínimo necesario para que pase; ejecuta la suite (verde).
- Refactoriza el código de producción y de pruebas manteniendo la suite en verde.
- Repite, añadiendo comportamientos a la lista a medida que los descubras.
##Pros & Cons
- Alta cobertura de pruebas como subproducto, no como ocurrencia tardía.
- La retroalimentación rápida detecta regresiones en cuestión de segundos.
- Fomenta diseños desacoplados y testeables.
- La suite actúa como documentación viva y ejecutable.
- Ritmo inicial más lento y una curva de aprendizaje real.
- Puede sobreenfatizar las unidades aisladas y pasar por alto huecos de integración.
- Las pruebas también son código: hay que mantenerlas y refactorizarlas.
- No sustituye a las pruebas exploratorias, de integración o de extremo a extremo.
