Generador de tests de casos límite: un prompt que prueba los bordes, no el camino feliz

Le pides a un modelo "escribe tests para esta función" y casi siempre te da lo mismo: cinco o seis casos que recorren el camino feliz con inputs válidos apenas distintos. Pasan, el número de cobertura sube, y despliegas una función que se cae la primera vez que alguien le pasa un array vacío o un string donde se esperaba un número. El problema no es que el modelo no sepa escribir tests. Es que el camino feliz es lo más fácil de generar, y los bugs viven en todo lo demás. Esta página te entrega un prompt que arregla el orden de las cosas: obliga al modelo a enumerar las formas en que un input podría romper la función antes de escribir un solo test, y después escribe un test deliberado por cada modo de fallo. Te llevas la plantilla, los placeholders, variantes para funciones puras, código async y handlers de API, y los detalles que vuelven peligrosos a los tests generados sin que te des cuenta.

01 · Por qué los modelos sobre-prueban el camino feliz

Un test de input válido que hace lo esperado es el más fácil de escribir, tanto para un modelo como para una persona. Sale directo del propósito de la función: la función suma dos números, así que el test suma dos números y comprueba el resultado. No hace falta imaginación. Por eso, cuando pides "unos tests", el modelo llena primero lo barato y se detiene apenas tiene una suite que se ve plausible.

El detalle es que el input válido rara vez rompe nada. Los bugs que llegan a producción viven en los bordes que el camino feliz nunca toca:

• Vacío y límite: el array vacío, el cero, el único elemento, el largo máximo, el off-by-one en el último índice.
• Ausente y mal formado: null, undefined, un campo faltante, el tipo equivocado, un número que llegó como string desde un formulario.
• Adversarial y raro: un par de surrogates unicode, un emoji que son dos unidades de código, un string que también es un número válido, una clave duplicada, un negativo donde diste por hecho un positivo.
• Concurrencia y orden: dos llamadas compitiendo, un callback que dispara dos veces, estado mutado entre la lectura y la escritura.

Ninguno de estos es exótico. Son justo los inputs que un sistema real le manda a una función un martes cualquiera con tráfico. La solución no es pedir "más tests", porque eso solo te da más tests del camino feliz. La solución es cambiar qué se genera primero.

02 · El prompt del generador de tests

Aquí tienes la plantilla. La jugada central es la estructura de dos pasos: primero enumera las categorías de input que rompen la función, y luego escribe exactamente un test enfocado por cada categoría. La línea de "qué categorías no aplican y por qué" es la que sostiene todo. Evita que el modelo invente tests irrelevantes solo para que la lista se vea completa. Pégala en un chat después de la función, o úsala como instrucción para un subagente que escribe tests.

Aquí tienes la firma de una función y su contrato. Quiero tests de casos límite,
no tests del camino feliz.

[pega la firma, el contrato / doc comment, y los tipos de los que depende]

PASO 1 — Taxonomía. Antes de escribir ningún test, lista las categorías de input
que podrían romper esta función. Considera al menos:
- vacío / largo cero
- límite (mínimo, máximo, primero, último, off-by-one)
- null / undefined / campo faltante
- tipo equivocado (string donde se espera un número, etc.)
- sobredimensionado / input muy grande
- valores duplicados / repetidos
- unicode / multi-byte / emoji
- números negativos o fuera de rango
- orden / concurrencia, si la función tiene estado o es async
- cualquier borde específico del dominio que no haya listado

Por CADA categoría, di en una línea: ¿aplica a ESTA función? Si no aplica, di por
qué (ej: "el input está tipado como tupla no vacía, el vacío es imposible"). No
escribas un test para una categoría que no puede darse.

PASO 2 — Tests. Por cada categoría que aplica, escribe UN test enfocado en
[mi framework, ej. Vitest]. Cada test debe:
- tener un nombre que enuncie el caso exacto ("retorna 0 para un array vacío").
- seguir arrange / act / assert, una aserción lógica por test.
- afirmar el comportamiento esperado EXACTO: el valor de retorno, O que lanza,
  O cuál error/mensaje específico. Marca con // VERIFY cualquier valor esperado
  que hayas inferido en vez de saberlo por el contrato.
- nunca repetir un camino que ya cubre otro test.

No pruebes el camino feliz más de una vez. Cierra con una lista corta: las
categorías que te saltaste y la razón.

Tres instrucciones son las que hacen el trabajo de verdad:

• "Taxonomía antes que los tests" obliga al modelo a pensar los modos de fallo como una categoría antes de casarse con casos concretos. Sin eso, va asociando libremente a partir del camino feliz.
• "¿Aplica? Si no, ¿por qué?" convierte la lista de categorías en un filtro, no en un checklist que hay que llenar. Una función tipada para recibir una tupla no vacía no debería recibir un test de input vacío, y el modelo debería decirlo en vez de escribir un test que ni siquiera compila.
• "Marca con // VERIFY cualquier valor esperado que inferiste" es la válvula de honestidad. El modelo no sabe qué string de error lanza tu código; con esto marca sus propias suposiciones en vez de presentártelas como hechos.

03 · La salida, y por qué igual tienes que correrla

Dale una función real y obtienes algo así: primero una pasada de taxonomía y luego tests dirigidos. Este ejemplo es un parser que convierte un string en un entero positivo o lanza una excepción.

import { describe, it, expect } from "vitest"
import { parsePositiveInt } from "./parse"

describe("parsePositiveInt: casos límite", () => {
  it("parsea un entero positivo normal", () => {
    expect(parsePositiveInt("42")).toBe(42)
  })

  it("lanza con un string vacío", () => {
    expect(() => parsePositiveInt("")).toThrow(/empty/) // VERIFY mensaje
  })

  it("lanza con un string no numérico", () => {
    expect(() => parsePositiveInt("abc")).toThrow()
  })

  it("lanza con un número negativo", () => {
    expect(() => parsePositiveInt("-3")).toThrow(/positive/) // VERIFY mensaje
  })

  it("rechaza un float, no trunca en silencio", () => {
    expect(() => parsePositiveInt("3.5")).toThrow() // VERIFY comportamiento
  })

  it("maneja espacios al inicio/final", () => {
    expect(parsePositiveInt("  7  ")).toBe(7) // VERIFY: ¿hace trim?
  })

  // saltados: unicode (input solo dígitos ASCII), concurrencia (fn pura)
})

Fíjate en los comentarios // VERIFY. El modelo en realidad no sabe si tu parser hace trim de los espacios, si lanza «empty» o «blank», o si trunca los floats en vez de rechazarlos. Todo eso lo dedujo a partir de un contrato plausible. Esos no son resultados de tests. Son hipótesis. El flujo es: corre la suite una vez, mira cuáles aserciones // VERIFY fallan, y decide en cada fallo si el que está mal es el test (corriges el valor esperado) o el código (encontraste un bug).

En eso consiste toda la disciplina: el modelo es bueno enumerando qué podría romperse y malo sabiendo cuál es tu comportamiento exacto. Déjalo encargarse de lo primero y tú te encargas de lo segundo. Esa división del trabajo es lo que hace que la salida sea confiable en vez de decorativa.

04 · Variantes para el código que de verdad escribes

El esqueleto se adapta a distintos tipos de código; cambias las categorías que importan y el estilo de las aserciones. Tres formas comunes:

Funciones puras

La plantilla por defecto ya está afinada para estas. Las categorías giran todas en torno al espacio de input: vacío, límite, tipo, unicode, rango. Agrega una línea pidiendo candidatos basados en propiedades si usas algo como fast-check: "Para cualquier categoría donde un solo ejemplo sea débil, sugiere una propiedad y un generador en vez de un caso fijo." Los límites son donde los tests de propiedades se ganan el sueldo.

Código async y con estado

Agrega de forma explícita las categorías de orden y tiempo, porque para una función pura ni existen:

• la promesa se rechaza, no solo resuelve
• dos llamadas compiten; la segunda llega antes de que la primera resuelva
• un timeout o una señal de abort dispara a mitad de camino
• el mismo evento se entrega dos veces (idempotencia)
• el estado se lee, luego otro camino lo muta y después se escribe

Dile al modelo que use fake timers o promesas controlables en vez de delays reales, para que los tests se mantengan rápidos y deterministas.

Handlers de rutas de API

Aquí el "input" es un request, así que la taxonomía se desplaza hacia la superficie del request:

• body faltante o mal formado, content-type equivocado
• body válido pero que no pasa la validación de negocio
• sin autenticar y sin autorizar (son casos distintos, un 401 no es un 403)
• la dependencia río abajo (DB, API upstream) falla o da timeout
• el mismo request reintentado (¿cobra doble, envía doble?)

05 · Detalles que convierten los tests generados en falsa confianza

Cada uno de estos se ve bien en el diff y debilita la suite sin que nadie lo note. Son la diferencia entre tests que atrapan bugs y tests que solo están ahí.

1. Confiar en los valores esperados que el modelo adivinó. Ya lo cubrimos, pero vale repetirlo: el modelo inventa mensajes de error y formas de retorno. La convención // VERIFY solo sirve si de verdad corres la suite y resuelves cada marca. Si te saltas ese paso, lo que afirmaste es pura ficción.

2. Aserciones demasiado laxas. Un test que solo comprueba "lanza" pasa igual de bien si lanzó el error correcto o un TypeError por un typo. Donde importe, afirma el tipo o el mensaje de error específico, pero amárralo a un substring estable, no a la frase completa, para que un retoque de redacción no rompa el test.

3. Probar el mock, no el código. Cuando el modelo mockea una dependencia, a veces afirma que el mock se llamó con ciertos args y se da por satisfecho, sin comprobar qué hizo la función con el resultado. Eso prueba tu setup del mock, no tu lógica. Asegúrate de que al menos una aserción sea sobre la salida o el efecto real de la función.

4. Dejar que infle la lista. Sin la cláusula de "cuáles no aplican y por qué", el modelo escribe un test de concurrencia para una función pura y uno de unicode para un parser numérico, solo por llenar categorías. Cada test irrelevante es mantenimiento que cargas para siempre. Conserva esa cláusula y rechaza tests para inputs imposibles.

5. Un test gigante con diez aserciones. A veces el modelo mete todos los casos en un solo bloque «it». Cuando falla, no hay forma de saber qué caso se rompió. Insiste en un test enfocado por caso. El nombre del fallo debería decirte exactamente qué hizo regresión.

6. Sin bordes del dominio. La taxonomía genérica atrapa bugs genéricos. No va a saber que tu "porcentaje de descuento" tiene que estar entre 0 y 100, ni que un pedido no puede enviarse antes de estar pagado. Agrega siempre los bordes específicos del dominio tú mismo; el modelo solo puede enumerar lo que infiere de los tipos.

Usado así, el prompt no es una forma de ahorrarte escribir tests. Es una forma de dejar de esquivar los tests difíciles. El modelo hace la parte en la que es bueno: enumerar modos de fallo más rápido y más completo de lo que lo harías tú a las 5 de la tarde de un viernes. Y tú haces la parte que él no puede: confirmar qué hace tu código de verdad. Córrelos una vez, resuelve cada // VERIFY, y terminas con una suite que documenta los bordes en vez de adular el camino feliz.