Hvordan bruker du en AI-assistent til å skrive enhetstester for en eksisterende funksjon?

Question

Accepted Answer

Brukt godt er en AI utmerket på **opptellings**delen av testing — den brainstormer grensekanter og skriver boilerplate raskt. Men du må **verifisere at påstandene er meningsfylte**, fordi en AI gjerne skriver tester som består uten å bevise noe.

## Arbeidsflyten

1. **Gi den funksjonen pluss kontrakten** — hva den skal gjøre, inndata-/utdatatypene, og hvordan den skal håndtere ugyldig inndata. Tester kan ikke være bedre enn spesifikasjonen du beskriver.
2. **Be eksplisitt om grensekanter** — grenser (0, tom, maks) og feilbaner (null, negativ, feil type), ikke bare den lykkeske banen.
3. **Verifiser at påstandene er meningsfylte** — en test som bekrefter kodens nåværende oppførsel (selv om den er buggy) er verdiløs. Sjekk at hver påstand koder den *tiltenkte* kontrakten.

## Eksempel

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

AI foreslo grensekantene (0 og 100) og feilbanen du kan glemme. Din oppgave er å bekrefte at `toBe(80)` er den *riktige* forventede verdien, ikke bare det funksjonen tilfeldigvis returnerer.

## Hvorfor det betyr noe

Den vanskelige delen av testing er ikke å skrive `test(...)`-blokkene — det er **tenke på tilfellene du ellers ville gått glipp av**, og en AI er genuint god til det omfanget. Men den vet ikke hva koden din *skal* gjøre hvis du ikke forteller den, så uten tilsyn pleier den å skrive **tester som speiler implementeringen** (de består, men de ville bestått selv om funksjonen var feil). Behandler du AI som en grensekant-generator mens du eier påstandene, får du bred dekning og ekte korrekthet — hastighet fra AI, dømmekraft fra deg.