Desarrollo guiado por tests (TDD)

¿Qué es el desarrollo guiado por tests?

El desarrollo guiado por tests es una práctica en la que escribes la prueba antes que el código que comprueba. El ritmo tiene nombre, rojo-verde-refactor, y se repite. Escribe una prueba para el comportamiento que quieres. Falla, porque el código aún no existe. Escribe el mínimo código para que pase. Luego limpia la estructura sin romper la prueba. Otra vuelta.

Escribir la prueba primero te obliga a decidir qué debe hacer un trozo de código antes de decidir cómo lo hará. Suena a un pequeño reordenamiento, pero cambia el diseño. Toma una función que calcula el coste de envío: la prueba fija las entradas y el total esperado antes de que exista una sola línea de lógica, así que el requisito queda clavado primero y la implementación tiene un objetivo claro al que llegar. Cada pieza de lógica llega con una prueba ya envuelta a su alrededor.

El TDD requiere disciplina, y es más lento en la primera hora y más rápido a lo largo del proyecto. El código escrito así tiende a ser más modular, documentado por sus propias pruebas y seguro de refactorizar después, porque la suite te avisa en el instante en que algo se rompe. Es una práctica de desarrollo, no un añadido de testing, que es justo la razón por la que funciona.

TDD en Dallonses

Recurrimos al TDD en las partes de un sistema donde la corrección no es negociable: lógica de pagos, reglas de precios, cualquier cosa donde un bug silencioso cueste dinero real. Escribir la prueba primero nos mantiene honestos con el requisito, y deja atrás una suite que documenta la intención mejor de lo que un comentario podría.

No es dogma. No guiamos por tests un prototipo desechable, y lo decimos. Donde el TDD se gana su coste, las pruebas se pliegan directamente en nuestro testing automatizado y el pipeline de CI, así que las mismas comprobaciones que dieron forma al código siguen vigilándolo en cada release. Nuestro trabajo de quality assurance de software es más fuerte por ello, y también la confianza del cliente a la hora de cambiar el código meses después.

¿Construyes lógica que tiene que estar bien a la primera? Guiemos por tests las partes que importan.

Hablemos de QA