Testdata is het stiefkind van elk test automation project.

Binnen elk team praat men over testcoverage, CI snelheid en de juiste tools. Bijna niemand praat over waar die tests hun data vandaan halen. Toch is dat vaak de stille oorzaak achter tests die willekeurig falen.

Toch is dat vaak de stille oorzaak achter tests die willekeurig falen, bugs die niemand kan reproduceren, en een suite waar het team stilaan het vertrouwen in verliest. Testdata verdient evenveel aandacht als de tests zelf, en krijgt in de praktijk bijna nooit die aandacht.

Wat er misgaat als je het negeert

Beide problemen voelen technisch, maar de oorzaak is bijna altijd organisatorisch: tests delen data met elkaar, of met een omgeving die ook door anderen wordt gebruikt. Zodra dat gebeurt, is het een kwestie van tijd voor de suite onbetrouwbaar wordt.

Testdata als code

De oplossing klinkt eenvoudiger dan ze is om structureel door te voeren: behandel testdata als code. Reproduceerbaar, geïsoleerd per test, en opgebouwd via factories of geïsoleerde fixtures in plaats van een gedeelde database die iedereen aanpast.

In de praktijk betekent dit dat elke test zijn eigen data opbouwt bij het begin, en niets gebruikt dat een andere test kan hebben gewijzigd. Dat voelt in het begin als extra werk. Het betaalt zichzelf snel terug zodra je merkt hoeveel tijd er nu verloren gaat aan het uitzoeken of een falende test een echte bug is, of gewoon data die niet meer klopt.

Zo'n factory hoeft niet complex te zijn — het punt is dat elke test zijn eigen, voorspelbare data krijgt:

// elke aanroep maakt een verse, geïsoleerde gebruiker aan
function createUser(overrides = {}) {
  return {
    id: crypto.randomUUID(),
    email: `test-${Date.now()}@qadvice.be`,
    role: 'customer',
    ...overrides
  };
}

// gebruik in de test: expliciet wat ertoe doet, de rest is default
test('een admin ziet het beheerpaneel', async () => {
  const admin = createUser({ role: 'admin' });
  await loginAs(admin);
  await expect(page.locator('#admin-panel')).toBeVisible();
});

Geen gedeelde database, geen opruimscript dat kan falen, geen test die faalt omdat een collega gisteren met dezelfde testgebruiker aan het testen was. Elke test brengt zijn eigen data mee en laat niets achter.

Waar je begint

Kijk eerst naar je meest flaky test. Negen van de tien keer zit het probleem niet in de test zelf, maar in de data eronder. Bouw die data op via een factory, isoleer ze van andere tests, en meet het verschil in stabiliteit. Doe dat een paar keer en je krijgt vanzelf het argument om het structureel aan te pakken voor de hele suite.

// Ook als carrousel

Dit artikel verscheen eerder als carrousel op LinkedIn.

Bekijk op LinkedIn