tddlisted

# tdd Disciplina que hermes-builder aplica dentro de `implement`. Garantiza el feedback loop que evita el "código roto". ## Qué es un buen test Los tests verifican **comportamiento a través de interfaces públicas**, no detalles de implementación. El código puede cambiar entero; los tests no deberían. Un buen test funciona como documentación ("el usuario puede pagar con un carrito válido") y sigue siendo válido tras un refactor porque ignora el mecanismo interno. ## Costuras (seams): dónde van los tests Una **costura** es el límite público donde puedes observar comportamiento sin mirar las tripas. **Prueba solo en las costuras acordadas** en la spec. Antes de empezar, ten claras esas costuras y confírmalas: evita cobertura de bajo valor y centra el esfuerzo en los caminos críticos. ## Anti-patrones a evitar 1. **Acoplado a implementación**: mockear colaboradores internos o testear métodos privados. 2. **Tautológico**: la aserción recalcula el valor esperado igual que la implementación. 3. **Rebanada horizontal**: escribir todos los tests antes de implementar. En su lugar, rebanadas verticales: un test → una implementación, ciclo a ciclo. ## Reglas del loop - Escribe el test que **falla** antes de la implementación. - Implementa el **código mínimo** para pasar cada test. - Un ciclo trabaja **una costura**. - El refactor grande va en el code-review/auditoría, no dentro del ciclo rojo-verde. - No se entrega un ticket con tests en rojo o saltados. ## Salida Código