Después de escribir una función nueva o antes de refactorizar. Te genera una suite de tests que cubre lo que no se te ocurriría.
El prompt
Eres un QA engineer que escribe tests con mentalidad destructiva: tu trabajo es romper el código, no confirmar que funciona.
Te voy a dar una función o módulo. Escribe tests unitarios que cubran:
1. HAPPY PATH: El caso normal que debería funcionar.
2. EDGE CASES:
- Inputs vacíos (null, undefined, '', [], {})
- Inputs en los límites (0, -1, MAX_INT, strings muy largos)
- Tipos incorrectos (string donde esperas number, etc.)
- Caracteres especiales y unicode
3. ERROR HANDLING: ¿Lanza las excepciones correctas? ¿Los mensajes de error son útiles?
4. CONCURRENCIA: Si aplica, ¿qué pasa con llamadas simultáneas?
5. INTEGRACIÓN: Si la función depende de servicios externos, mockéalos y testa los fallos (timeout, 500, respuesta malformada).
Para cada test:
- Nombre descriptivo que diga qué testa y qué espera
- Arrange / Act / Assert claramente separados
- Comentario de 1 línea explicando POR QUÉ este test importa
Framework de test: [indicar: pytest, jest, etc.]
Código a testar: [pegar]
Cómo usarlo
Modelo recomendado: Claude
Ejemplo de input
[Función Python que calcula descuentos: apply_discount(price, discount_percent)]
Ejemplo de output
def test_apply_discount_normal(): # Happy path: 20% de descuento sobre 100 assert apply_discount(100, 20) == 80.0
def test_apply_discount_zero_percent(): # Edge: descuento 0% no debería modificar el precio assert apply_discount(50, 0) == 50.0
def test_apply_discount_negative_price_raises(): # Error: precio negativo es inválido with pytest.raises(ValueError): apply_discount(-10, 20)
Contexto
Cómo escribir tests unitarios con IA que encuentren bugs de verdad
La mayoría de developers escriben tests que confirman que su código funciona. El problema es que los bugs no están en el happy path. Están en el input vacío que nadie probó, en el número negativo que nadie esperaba, en el timeout del servicio externo que siempre funciona... hasta que no.
Este prompt genera tests con mentalidad destructiva. No busca confirmar que el código funciona, busca romperlo. Cubre cinco categorías: happy path, edge cases, error handling, concurrencia e integración con servicios externos.
Cada test tiene nombre descriptivo, estructura Arrange/Act/Assert limpia, y un comentario explicando por qué ese test importa. Porque un test sin explicación es un test que alguien borrará cuando falle sin entender por qué existía.
Funciona con cualquier framework (pytest, jest, JUnit) y cualquier lenguaje. Solo indícale cuál usas y pega el código.