Hvordan bruger du en AI-assistent til at skrive unit tests for en eksisterende funktion?

Question

Accepted Answer

Hvis det bruges korrekt, er en AI udmærket til **enumerations**-delen af testing — den brainstormer edge cases og skriver boilerplate hurtigt. Men du skal **verificere, at assertions er meningsfulde**, fordi en AI gerne vil skrive tests, der består uden at bevise noget som helst.

## Arbejdsgangen

1. **Giv den funktionen plus dens kontrakt** — hvad den skal gøre, input/output-typerne, og hvordan den skal håndtere ugyldigt input. Tests kan ikke være bedre end den spec, du beskriver.
2. **Spørg eksplicit om edge cases** — grænser (0, tom, max), og fejlveje (null, negativ, forkert type), ikke kun happy path.
3. **Verificer, at assertions er meningsfulde** — en test, der assert kodens nuværende adfærd (selvom buggy) er værdiløs. Kontroller, at hver assertion koder den *tilsigtede* kontrakt.

## 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'en foreslog grænsecaserne (0 og 100) og fejlvejen, som du måske ville glemme. Dit job er at bekræfte, at `toBe(80)` er den *korrekte* forventede værdi, ikke bare hvad funktionen tilfældigvis returnerer.

## Hvorfor det betyder noget

Det svære ved testing er ikke at skrive `test(...)`-blokke — det er at **tænke på de cases, du ellers ville misse**, og en AI er virkelig god til denne bredde. Men den har ingen ide om, hvad din kode *skal* gøre, medmindre du fortæller det, så uden kontrol har den tendens til at skrive **tests, der afspejler implementeringen** (de består, men de ville bestå selv hvis funktionen var forkert). At behandle AI'en som en edge-case-generator, mens du ejer assertions, giver dig bred dækning og reel korrekthed — hastighed fra AI'en, vurdering fra dig.