¿Cómo utilizas un asistente de IA para escribir pruebas unitarias para una función existente?

Question

Accepted Answer

Utilizado correctamente, la IA es excelente en la parte de **enumeración** de las pruebas — genera lluvia de ideas sobre casos extremos y escribe el código repetitivo rápidamente. Pero debes **verificar que las aserciones sean significativas**, porque la IA escribirá felizmente pruebas que pasen sin probar nada.

## El flujo de trabajo

1. **Dale la función más su contrato** — qué debe hacer, los tipos de entrada/salida y cómo debe manejar la entrada inválida. Las pruebas no pueden ser mejores que la especificación que describes.
2. **Pide explícitamente casos extremos** — límites (0, vacío, máximo) y rutas de error (null, negativo, tipo incorrecto), no solo la ruta feliz.
3. **Verifica que las aserciones sean significativas** — una prueba que afirma el comportamiento actual del código (aunque sea defectuoso) es inútil. Comprueba que cada aserción codifique el contrato *previsto*.

## Ejemplo

```js
// Function under test, with its contract:
// applyDiscount(price, percent) -> price reduced by percent.
// Contract: percent must be 0..100; throws RangeError otherwise. price >= 0.
function applyDiscount(price, percent) {
  if (percent < 0 || percent > 100) throw new RangeError('percent out of range');
  return price - (price * percent) / 100;
}
```

```js
// AI-suggested test cases (Jest) — note the edge and error paths, not just happy path:
test('applies a normal discount', () => {
  expect(applyDiscount(100, 20)).toBe(80);       // happy path
});
test('0% leaves price unchanged', () => {
  expect(applyDiscount(100, 0)).toBe(100);       // boundary: lower edge
});
test('100% makes it free', () => {
  expect(applyDiscount(100, 100)).toBe(0);       // boundary: upper edge
});
test('rejects percent above 100', () => {
  expect(() => applyDiscount(100, 150)).toThrow(RangeError); // error path
});
```

La IA propuso los casos límite (0 y 100) y la ruta de error que podrías olvidar. Tu trabajo es confirmar que `toBe(80)` es el valor esperado *correcto*, no solo lo que la función sucede que devuelve.

## Por qué es importante

La parte difícil de las pruebas no es escribir los bloques `test(...)` — es **pensar en los casos que de otro modo pasarías por alto**, y la IA es genuinamente buena en esa amplitud. Pero no tiene idea de qué se *supone* que debe hacer tu código a menos que se lo digas, así que sin control tiende a escribir **pruebas que reflejan la implementación** (pasan, pero pasarían incluso si la función fuese incorrecta). Tratar la IA como un generador de casos extremos mientras tú controlas las aserciones te da cobertura amplia y corrección real — velocidad de la IA, criterio tuyo.