Property-baserad testning av AI-kod: hitta gränsfallet som exemplen missar

Tre gröna exempel missar samma avrundningsfel

Anta att en AI-assistent skriver en funktion som fördelar ett helt antal ören proportionellt efter positiva vikter. Den här implementationen ser rimlig ut och varje del avrundas till ett heltal:

export function fordela(total, vikter) {
  const viktSumma = vikter.reduce((summa, vikt) => summa + vikt, 0);
  return vikter.map((vikt) =>
    Math.round((total * vikt) / viktSumma)
  );
}

Tre handvalda tester går igenom: 100 öre med vikterna [1, 1] blir [50, 50], 100 med [1, 3] blir [25, 75] och 1 000 med [2, 3, 5] blir [200, 300, 500]. Exemplen delar sig rent. De provar aldrig vad som händer när flera andelar behöver avrundas samtidigt.

För fordela(1, [1, 1]) blir resultatet däremot [1, 1]. Funktionen har skapat ett extra öre. Det är ett litet motexempel mot en grundläggande regel och exakt den sorts gränsfall som kan gömma sig bakom många plausibla AI-genererade exempeltester. Den breda guiden till testning av AI-genererad kod äger teststrategin; här isolerar vi tekniken som genererar indata från en sådan regel.

Skriv domänen före invarianten

Meningen “fördelningen ska alltid bli rätt” går inte att köra. Börja med vilka värden funktionen faktiskt lovar att hantera. I exemplet är domänen:

• total är ett heltal mellan 0 och 1 000 000 öre.
• vikter innehåller mellan 1 och 8 heltal.
• Varje vikt ligger mellan 1 och 100, alltså finns inga negativa eller nollstora vikter.

Först därefter kommer invarianten. Resultatet ska ha lika många delar som vikter, varje del ska vara ett icke-negativt heltal och summan av delarna ska vara exakt total. Lägg märke till vad som inte står där: testet kräver inte en viss avrundningsmetod eller exakt vilken mottagare som får restöret. Det bevakar det publika kontraktet utan att låsa implementationen.

Kör egenskapen med avgränsad indata och fast seed

Exemplet nedan använder fast-check tillsammans med Vitest. I fast-check består ett test av arbitraries som genererar och krymper värden, en property som beskriver egenskapen och en runner som bestämmer hur testet körs ^[1]. Här är alla tre delarna synliga:

import fc from 'fast-check';
import { expect, test } from 'vitest';
import { fordela } from './fordela.js';

const giltigaVikter = fc.array(
  fc.integer({ min: 1, max: 100 }),
  { minLength: 1, maxLength: 8 }
);

test('bevarar totalsumman för giltig indata', () => {
  fc.assert(
    fc.property(
      fc.integer({ min: 0, max: 1_000_000 }),
      giltigaVikter,
      (total, vikter) => {
        const delar = fordela(total, vikter);

        expect(delar).toHaveLength(vikter.length);
        expect(delar.every(Number.isInteger)).toBe(true);
        expect(delar.every((del) => del >= 0)).toBe(true);
        expect(delar.reduce((summa, del) => summa + del, 0))
          .toBe(total);
      }
    ),
    { seed: 20260821, numRuns: 500 }
  );
});

Seed-värdet gör den genererade följden repeterbar ^[2]. Det betyder inte att 500 körningar bevisar egenskapen för alla möjliga värden; det betyder att du har tagit 500 deterministiskt återskapbara stickprov ur den avgränsade domänen. Körningen är ett komplement till resonemanget, inte ett matematiskt bevis.

Det viktigaste kvalitetsarbetet ligger i generatorn. En heltalsgenerator med miljonspann och en kort lista av positiva vikter speglar kontraktet bättre än godtycklig JSON. Om produktionen även tillåter decimalvikter, tomma listor eller negativa justeringar ska de fallen få egna regler och egna properties. Göm inte en osäker domän bakom ett brett filter bara för att få testet grönt.

Läs det krympta motexemplet som en felrapport

När egenskapen faller rapporterar fast-check ett seed-värde, en path, motexemplet och hur många krympningssteg som gjordes. Dokumentationen visar att samma seed och path kan läggas i parametrarna till fc.assert för att gå direkt till det reducerade fallet ^[3]:

fc.assert(egenskapen, {
  seed: -1819918769,
  path: '0:...:3',
  endOnFailure: true
});

Siffrorna ovan är dokumentationens format, inte värden du ska kopiera. Använd seed och path från din felrapport. Path pekar körningen mot det redan krympta fallet, medan endOnFailure stoppar vid första fel i stället för att fortsätta krympa ^[3].

Krympningen är diagnosen. En stor slumpad lista kan få dig att misstänka ordning, overflow eller en enskild märklig vikt. Motexemplet total = 1 och vikter = [1, 1] visar i stället mekanismen: två separata avrundningar uppåt skapar mer än totalen. fast-check beskriver krympning som att ett felande värde reduceras mot ett enklare värde som fortfarande får egenskapen att falla ^[2].

Bevara värdet, inte bara slumpen

Seed och path är praktiska under felsökning, men regressionstestet ska visa buggen utan att vara beroende av hur en generator råkar traversera sina värden. Spara därför det krympta motexemplet som ett vanligt test:

test('tappar eller skapar inte ören vid lika vikter', () => {
  const delar = fordela(1, [1, 1]);
  expect(delar.reduce((summa, del) => summa + del, 0)).toBe(1);
});

Testet låser inte vilken del som får öret. Både [1, 0] och [0, 1] kan vara giltiga om kontraktet tillåter det. Det låser bara det fel som faktiskt hittades: summan får inte förändras. Behåll samtidigt property-testet. Regressionstestet skyddar det kända fallet vid varje körning; property-testet fortsätter leta efter nästa kombination du ännu inte känner till.

Det här skiljer tekniken från mutationstestning av AI-genererade tester. Mutationstestning ändrar implementationen och frågar om testsviten reagerar. Property-baserad testning ändrar indata och frågar om implementationen fortfarande uppfyller en egenskap. De kan kombineras, men de mäter inte samma sak.

När ett vanligt exempeltest är bättre

Property-baserad testning passar när många giltiga indata delar samma relation: sortering bevarar element, kodning och avkodning är varandras inverser, en parser kraschar inte för giltigt format eller en fördelning bevarar totalsumman. Ett vanligt exempeltest är tydligare när rätt resultat är en specifik produktregel.

I en kodgranskning av AI-genererad kod räcker därför tre frågor långt: vilken invariant bevakas, vilka värden räknas som giltiga och vilket explicit test sparades när property-körningen hittade ett fel? Saknas ett tydligt svar är många genererade körningar bara en större grön yta.