Come usi un assistente AI per scrivere unit test per una funzione esistente?

Question

Accepted Answer

Se usato bene, un AI è eccellente nella parte di **enumerazione** del testing — genera brainstorming di casi limite e scrive il boilerplate velocemente. Ma devi **verificare che le asserzioni siano significative**, perché un AI scriverà felicemente test che passano senza provare nulla.

## Il workflow

1. **Dagli la funzione più il suo contratto** — cosa dovrebbe fare, i tipi di input/output, e come dovrebbe gestire input non valido. I test non possono essere migliori della spec che descrivi.
2. **Chiedi esplicitamente casi limite** — confini (0, vuoto, massimo), e percorsi di errore (null, negativo, tipo sbagliato), non solo il happy path.
3. **Verifica che le asserzioni siano significative** — un test che asserisce il comportamento attuale del codice (anche se buggy) è inutile. Controlla che ogni asserzione codifichi il contratto *inteso*.

## Esempio

```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
});
```

L'AI ha proposto i casi limite (0 e 100) e il percorso di errore che potresti dimenticare. Il tuo compito è confermare che `toBe(80)` è il valore atteso *corretto*, non solo quello che la funzione capita di restituire.

## Perché è importante

La parte difficile del testing non è digitare i blocchi `test(...)` — è **pensare ai casi che altrimenti perderesti**, e un AI è genuinamente bravo in quella vastità. Ma non ha idea di cosa il tuo codice *dovrebbe* fare a meno che non glielo dici, quindi se non controllato tende a scrivere **test che specchiano l'implementazione** (passano, ma passerebbero anche se la funzione fosse sbagliata). Trattare l'AI come un generatore di casi limite mentre tu possiedi le asserzioni ti dà copertura ampia e vera correttezza — velocità dall'AI, giudizio da te.