Cómo pedir tests que prueben comportamiento y casos límite en lugar de repetir la implementación, cómo detectar los tautológicos y cómo comprobar que la suite detecta fallos de verdad.
Cuándo usarlo: Generar tests con IA que prueben comportamiento y casos límite, y verificar que la suite detecta fallos reales en lugar de confirmar la implementación
Herramienta recomendada: Claude Code
Actúa como ingeniero especializado en calidad de software. Quiero usar IA para ampliar la cobertura de tests sin acabar con cientos de tests que pasan siempre y no detectan nada. ## Contexto que necesito 1. Lenguaje, framework de tests y estilo actual de la suite. 2. El código a cubrir (pégalo o indícame los ficheros). 3. Cobertura actual, si la conoces, y los fallos que se han escapado a producción últimamente. ## El problema de fondo Un modelo que ve tu implementación tiende a escribir tests que la describen: si el código está mal, el test también, y todo pasa en verde. Los síntomas del test tautológico: - Reproduce la fórmula del código en el valor esperado en lugar de escribir el resultado a mano. - Solo prueba el camino feliz con datos redondos. - Simula (mockea) tanto que lo único que verifica es que se llamó a un simulacro. - El nombre del test describe la implementación («llama al repositorio»), no el comportamiento («devuelve error si el pedido ya está pagado»). ## Paso 1 — Primero el contrato, luego el test Antes de escribir tests, describe el comportamiento esperado del código sin mirar la implementación: entradas válidas, salidas esperadas, errores previstos, efectos secundarios y qué no debe ocurrir. Si al derivar el contrato aparece una ambigüedad, es un hallazgo: pregúntame en lugar de asumir. ## Paso 2 — Genera los casos por categorías Para cada función o endpoint, cubre: | Categoría | Qué incluir | |---|---| | Camino esperado | Uno o dos casos representativos, con valores realistas | | Límites | Vacío, uno, máximo, máximo+1, cero, negativo | | Tipos y formatos | Nulo, cadena en lugar de número, fecha inválida, codificación rara | | Estado previo | Recurso inexistente, ya modificado, permisos insuficientes | | Concurrencia | Dos operaciones simultáneas sobre el mismo recurso, cuando aplique | | Regresión | Un test por cada fallo que ya ocurrió una vez | Los valores esperados se escriben a mano, calculados por una persona. Nunca copiando la expresión del código. ## Paso 3 — Comprobar que la suite detecta fallos La prueba de fuego: introduce deliberadamente tres errores pequeños en el código (invierte una condición, cambia un límite, elimina una validación) y comprueba si algún test falla. Si pasa todo en verde, la suite es decorativa. Entrega el resultado de este ejercicio. ## Paso 4 — Higiene de la suite - Tests independientes y con datos propios; sin orden implícito. - Nada de esperas por tiempo; control explícito del reloj y de la aleatoriedad. - Un motivo de fallo por test, para que el nombre del test diga qué se rompió. - Simulacros solo en los bordes del sistema (red, reloj, sistema de ficheros). ## Entregables 1. Contrato de comportamiento derivado, con las ambigüedades señaladas. 2. Los tests, agrupados por categoría y listos para pegar. 3. Resultado del ejercicio de los tres errores introducidos. 4. Lista de tests existentes que conviene borrar por tautológicos o duplicados. 5. Qué quedaría sin cubrir y por qué no compensa cubrirlo.