Escritor de Documentacion de Tests

El Problema

Cada equipo reinventa las convenciones de testing. Los nuevos desarrolladores preguntan “Donde van los tests?”, “Como nombro los tests?”, “Mockeamos la base de datos o usamos una real?”. Sin estandares escritos, cada desarrollador sigue sus propios patrones, creando una suite de tests inconsistente. La documentacion de tests es aburrida de escribir pero critica para la alineacion del equipo — lo que la hace una tarea perfecta para la IA.

El Prompt

Genera un documento de estrategia de testing para mi proyecto. Este sera la fuente unica de verdad de como nuestro equipo escribe, organiza y ejecuta tests.

PROYECTO: [describe tu proyecto — tipo, tamano, stack tecnologico, tamano del equipo]
ESTADO ACTUAL: [describe el testing actual]

Genera una guia de testing completa cubriendo:

1. **Piramide de Testing** — Definir el ratio y proposito de cada capa de tests
2. **Organizacion de Archivos** — Donde viven los archivos de test, convencion de nombres
3. **Convenciones de Nombres** — Patron para casos de test y bloques describe
4. **Patrones de Testing** — Patrones estandar para AAA, decisiones de mocking, async, componentes
5. **Requisitos de CI** — Que debe pasar antes de merge
6. **Anti-Patrones** — Que NO hacer

Incluir ejemplos de codigo para cada patron y anti-patron.

Ejemplo de Salida

# Guia de Testing

## Convencion de Nombres
Los tests siguen el patron: `debe [comportamiento] cuando [condicion]`

// BIEN
it('debe retornar 401 cuando el token esta expirado')
it('debe mostrar mensaje de error cuando falla el envio del formulario')

// MAL
it('test login')
it('funciona correctamente')

Cuando Usar

Al inicio de un proyecto nuevo, al incorporar nuevos miembros del equipo, o cuando tus tests existentes son inconsistentes y necesitan estandarizacion. Este documento debe vivir en tu repo y actualizarse trimestralmente.

Tips Pro

• Generar desde tus tests existentes — pegar 3-5 de tus mejores archivos de test y pedir a la IA “Extrae los patrones de estos tests en un documento de convenciones.”
• Incluir ejemplos de anti-patrones — los desarrolladores aprenden tanto de “no hagas esto” como de “haz esto.”
• Agregar un arbol de decisiones — “Debo escribir un test unitario, de integracion o E2E para este cambio?”
• Mantenerlo corto — una guia de 2 paginas que todos leen vence a una guia de 20 paginas que nadie lee.