Encaja muy bien en
- Lógica de dominio con reglas claras y casos borde.
- APIs nuevas con contratos todavía en diseño.
- Módulos críticos donde romper cuesta caro.
No siempre conviene empezar por TDD
- Spikes exploratorios o prototipos descartables.
- Integraciones muy inestables sin contrato definido.
- Tareas 100% de wiring sin lógica propia.
Escribe primero una prueba que falla por comportamiento aún no implementado.
Implementa lo mínimo para pasar, sin adelantarte a escenarios no requeridos.
Mejora diseño y legibilidad manteniendo la red de seguridad de pruebas en verde.
MICRO-CICLO TDD — JAVA (RED → GREEN)
// RED
@Test
void shouldApplyTenPercentDiscountForVipCustomer() {
PriceCalculator calc = new PriceCalculator();
BigDecimal total = calc.finalPrice(BigDecimal.valueOf(100), true);
assertEquals(BigDecimal.valueOf(90), total);
}
// GREEN (mínimo para pasar)
public BigDecimal finalPrice(BigDecimal base, boolean vip) {
return vip ? base.multiply(BigDecimal.valueOf(0.9)) : base;
}
Empieza por casos simples y deja que aparezcan abstracciones cuando ya hay duplicación real.
Prefiere fakes para flujos de negocio; usa mocks cuando necesites verificar interacción explícita.
Regla operativa: en TDD no diseñas “todo” antes; diseñas el siguiente paso que la prueba actual te exige, y refactorizas con evidencia.
Cuando un test valida demasiadas cosas, falla sin indicar causa y bloquea refactor.
Pruebas frágiles que dependen de internals rompen con cualquier mejora de diseño.
Acumular “greens” sin limpiar deriva en deuda técnica y pérdida de velocidad futura.
Evita falsos rojos por setup incorrecto.
No implementar features no pedidas por la prueba.
Ejecuta suite relevante tras cada limpieza importante.
El test debe leerse como documentación viva.