Programador Par TDD

El Problema

Test-Driven Development es poderoso pero mentalmente demandante. Necesitas cambiar de contexto constantemente entre modos de “autor de tests” e “implementador”. La mayoria de los desarrolladores abandonan TDD no porque esten en desacuerdo, sino porque mantener la disciplina de escribir un test que falle antes de cada cambio de codigo es agotador. Tener un companero IA que refuerce el ciclo red-green-refactor te mantiene disciplinado y duplica tu velocidad.

El Prompt

Eres mi programador par TDD. Seguiremos disciplina estricta Red-Green-Refactor.

FEATURE A CONSTRUIR:
[describe el feature o comportamiento en lenguaje simple]

LENGUAJE/FRAMEWORK: [ej. TypeScript + Vitest, Python + pytest]

Reglas para nuestra sesion TDD:
1. **RED** — Tu escribes UN test que falla para la pieza mas pequena de comportamiento
2. **GREEN** — Yo implemento el codigo minimo para que pase (o tu lo sugieres)
3. **REFACTOR** — Tu revisas y sugieres refactoring manteniendo los tests verdes

Despues de cada paso:
- Muestrame el archivo de test actual y el archivo de implementacion
- Dime en que paso estamos (RED / GREEN / REFACTOR)
- Sugiere el siguiente test a escribir basado en los requerimientos del feature

Comenzar con el caso de test mas simple posible. Construir complejidad gradualmente — nunca adelantarse. Cada test debe agregar exactamente UN comportamiento nuevo.

Comienza ahora: escribe el primer test que falla.

Ejemplo de Salida

PASO 1: RED — Primer test que falla

// password-validator.test.ts
describe('PasswordValidator', () => {
  it('debe rechazar passwords vacios', () => {
    expect(validatePassword('')).toEqual({
      valid: false,
      errors: ['El password es requerido']
    });
  });
});

Este test fallara porque validatePassword() no existe todavia.

TU TURNO: Crea la funcion con justo el codigo necesario para que este test pase.

Cuando Usar

Usar para cualquier feature nuevo donde los requerimientos son lo suficientemente claros para expresarlos como tests. Es especialmente efectivo para logica de negocio, reglas de validacion, maquinas de estado y algoritmos. Evitar para codigo muy visual o prototipado exploratorio donde los requerimientos aun no estan claros.

Tips Pro

• Empezar con el caso degenerado — input vacio, null, cero. Son los tests mas simples y establecen la firma de la funcion naturalmente.
• Una asercion por test — resistir la tentacion de testear multiples comportamientos en un paso. Cada paso RED debe introducir exactamente un requerimiento nuevo.
• Pedir un roadmap de tests primero — promptear “Antes de empezar a codificar, lista los 8-12 tests que escribiremos en orden, del mas simple al mas complejo.”
• Tomar en serio el paso de refactor — despues de cada 3-4 tests verdes, promptear “Revisa la implementacion buscando duplicacion, nombres y patrones de diseno. Sugiere refactorizaciones manteniendo todos los tests verdes.”