Desarrollo Guiado por Pruebas
TDD es el bucle rojo → verde. Esta habilidad es la referencia que hace que ese bucle produzca pruebas que valga la pena conservar: qué es una buena prueba, dónde van las pruebas, los anti-patrones y las reglas del bucle. Cada sección se aplica en cada ciclo: consúltalas antes y durante el bucle, no después.
Al explorar el código base, lee GLOSSARY.md (si existe) para que los nombres de las pruebas y el vocabulario de la interfaz coincidan con el lenguaje del dominio del proyecto, y respeta las ADR en el área que estás tocando.
Qué es una buena prueba
Las pruebas verifican el comportamiento a través de interfaces públicas, no detalles de implementación. El código puede cambiar por completo; las pruebas no deberían. Una buena prueba se lee como una especificación: "el usuario puede finalizar la compra con un carrito válido" te dice exactamente qué capacidad existe, y sobrevive a las refactorizaciones porque no le importa la estructura interna.
Consulta tests.md para ver ejemplos y mocking.md para las pautas de mocking.
Costuras: dónde van las pruebas
Una costura es el límite público en el que pruebas: la interfaz donde observas el comportamiento sin acceder al interior. Las pruebas viven en las costuras, nunca contra elementos internos.
Prueba solo en costuras acordadas previamente. Antes de escribir cualquier prueba, escribe las costuras bajo prueba y confírmalas con el usuario. No se escribe ninguna prueba en una costura no confirmada. No puedes probarlo todo, así que acordar las costuras de antemano es cómo el esfuerzo de las pruebas se centra en las rutas críticas y la lógica compleja, en lugar de en cada caso extremo.
Pregunta: "¿Cuál es la interfaz pública y qué costuras deberíamos probar?" Da a cada costura propuesta una nota de una línea sobre qué captura y qué omite.
Cuando la forma de esa interfaz esté en cuestión (qué tan profundo es el módulo, dónde pertenece la costura, qué debería exponer la interfaz), invoca la herramienta Skill con "codebase-design" para obtener el vocabulario. Es la fuente compartida de los términos módulo, interfaz, profundidad, costura, adaptador, apalancamiento y localidad, y es una referencia a consultar, no una sesión para ejecutar.
Anti-patrones
- Acoplado a la implementación: simula colaboradores internos, prueba métodos privados o verifica a través de un canal secundario (consultando la base de datos en lugar de usar la interfaz). La señal: la prueba se rompe cuando refactorizas pero el comportamiento no ha cambiado.
- Tautológico: la aserción recalcula el valor esperado de la misma manera que el código (
expect(add(a, b)).toBe(a + b), una instantánea derivada manualmente de la misma forma, una constante afirmada igual a sí misma), por lo que pasa por construcción y nunca puede discrepar del código. Los valores esperados deben provenir de una fuente de verdad independiente: un literal conocido como correcto, un ejemplo resuelto, la especificación. - Segmentación horizontal: escribir todas las pruebas primero y luego toda la implementación. Las pruebas masivas verifican un comportamiento imaginado: pruebas la forma de las cosas en lugar del comportamiento orientado al usuario, las pruebas se vuelven insensibles a cambios reales y te comprometes con la estructura de las pruebas antes de comprender la implementación. Trabaja en rebanadas verticales en su lugar: una prueba → una implementación → repite, cada prueba es una bala trazadora que responde a lo que te enseñó el último ciclo.
Reglas del bucle
- Rojo antes que verde. Escribe la prueba fallida primero, luego solo el código suficiente para pasarla. No anticipes pruebas futuras ni agregues funcionalidades especulativas.
- Una rebanada a la vez. Una costura, una prueba, una implementación mínima por ciclo.
- La refactorización no es parte del bucle. Pertenece a la etapa de revisión (consulta la habilidad
code-review), no al ciclo de implementación rojo → verde.