De build wordt rood, iemand klikt op “opnieuw uitvoeren”, de build gaat voorbij en iedereen gaat verder. Het lijkt onschuldig, maar slechte tests vernietigen langzaam het meest waardevolle dat een testsuite heeft: het vertrouwen van mensen erin. Wanneer fouten meestal ruis zijn, worden echte bugs er ook doorheen gezwaaid.

In deze gids wordt beschreven waarom tests onnauwkeurig worden en hoe u elke oorzaak op de juiste manier kunt oplossen. We hebben de timing- en gedeelde-statusdemo’s uitgevoerd in Python 3.13, en de getoonde cijfers zijn afkomstig van die runs. Het zijn kleine demonstraties die zijn ontworpen om de schilfering gemakkelijk zichtbaar te maken, zodat uw eigen faalpercentages zullen verschillen.

Wat is een vloktest?

Een vlokkige test geeft verschillende resultaten op dezelfde code. Het gaat de ene run door en mislukt de volgende, ook al is er niets aan het product veranderd. Het kan zijn dat de test een fout bevat, of dat de code een echte periodieke bug bevat. Die tweede mogelijkheid is precies de reden waarom je ze niet zomaar van de hand moet wijzen.

Waarom vlokkige tests zo duur zijn

• Verloren vertrouwen. Zodra mensen aannemen dat rood ‘waarschijnlijk schilferig’ betekent, stoppen ze met het onderzoeken van echte mislukkingen.
• Verspilde tijd. Ontwikkelaars besteden uren aan het opnieuw uitvoeren van pipelines en het onderzoeken van fouten die niets met de wijziging te maken hebben.
• Langzamere levering. Samenvoegingen en releases wachten op herhalingen, waardoor het punt van CI/CD wordt ondermijnd.
• Verborgen bugs. Raceomstandigheden in het product kunnen op testgeluid lijken, en dat zijn de problemen die tijdens de productie pijn doen.

Veelvoorkomende oorzaken in één oogopslag

Oorzaak 1: Timing en vaste slaapplaatsen

Dit is de meest voorkomende oorzaak. Bij een test wordt ervan uitgegaan dat het achtergrondwerk na een vaste vertraging wordt afgerond. Om het effect te zien, hebben we een kleine test geschreven waarbij het werk maximaal 2 ms duurt, terwijl de test slechts 1 ms wacht voordat hij controleert:

def flaky_timing():
    result = {}
    def work():
        time.sleep(random.uniform(0, 0.002))
        result["done"] = True
    threading.Thread(target=work).start()
    time.sleep(0.001)        # hope it has finished
    assert result.get("done")

De oplossing is wachten op de werkelijke toestand, met een royale bovengrens:

def fixed_timing():
    result = threading.Event()
    def work():
        time.sleep(random.uniform(0, 0.002))
        result.set()
    threading.Thread(target=work).start()
    assert result.wait(timeout=1)   # continues as soon as it is ready

We hebben elke versie 200 keer uitgevoerd:

Het resultaat is meer dan alleen betrouwbaarheid. De vaste versie beweegt mee op het moment dat het werk klaar is, dus meestal ook sneller. Een langere slaapstand zou ervoor zorgen dat de eerste versie minder vaak faalt, maar elke run zou dan langzamer zijn, en deze zou nog steeds kunnen mislukken op een drukke CI-machine.

Bij browsertests geldt hetzelfde principe. Gebruik het automatische wachten van Toneelschrijver, of expliciete Selenium wacht, in plaats van time.sleep:

# Playwright: retries until true or a timeout is reached
expect(page.get_by_text("Order placed")).to_be_visible()

# Selenium: an explicit wait for a condition
WebDriverWait(driver, 10).until(
    EC.visibility_of_element_located((By.ID, "confirmation"))
)

Oorzaak 2: gedeelde status en testopdracht

Wanneer tests gegevens delen, kan de ene de andere beïnvloeden, en het resultaat hangt af van de volgorde waarin ze worden uitgevoerd. Deze twee tests gebruiken één gedeelde lijst:

store = []

def test_add():
    store.append("x")
    assert len(store) == 1

def test_empty():
    assert store == []

Onze run bevestigde dit, en daarom kan een suite maandenlang meegaan en dan kapot gaan als iemand parallelle runs of een willekeurige volgorde-plug-in toevoegt. De remedie is isolatie:

• Geef elke test nieuwe gegevens, met behulp van een apparaat dat de test instelt en opruimt. Onze pytest-tutorial laat zien hoe.
• Creëer unieke records, zoals een e-mail met een willekeurig achtervoegsel, in plaats van een gedeelde “testgebruiker”.
• Verpak databasetests in een transactie en draai deze terug, voor zover uw configuratie dit toestaat.
• Voer regelmatig tests in willekeurige volgorde uit, zodat deze problemen vroegtijdig opduiken.

Oorzaak 3: Datums, tijdzones en willekeur

Een toets die de hele week doorgaat, kan mislukken op zaterdag, om middernacht of op de laatste dag van de maand. Maak van tijd een input, in plaats van de klok in uw logica af te lezen:

def is_weekend(today=None):
    today = today or datetime.date.today()
    return today.weekday() >= 5

is_weekend(datetime.date(2026, 11, 7))   # True  (a Saturday)
is_weekend(datetime.date(2026, 11, 9))   # False (a Monday)

Die tests geven op elke dag hetzelfde antwoord. Stel op dezelfde manier een vast zaad in voor willekeurige waarden in tests, en log dit wanneer u willekeurige gegevens gebruikt, zodat u een fout kunt reproduceren. Ga niet uit van een bepaalde volgorde van sets, woordenboeken uit externe bronnen of databasequery’s zonder ORDER BY.

Oorzaak 4: brosse selectors

Een test die een knop met div:nth-child(3) > span vindt, breekt bij elke aanpassing van de lay-out, en mislukt mogelijk alleen voor bepaalde schermformaten of varianten. Geef de voorkeur aan locators op basis van wat gebruikers zien, of aan speciale testattributen. In onze gids voor Playwright-locators wordt de volgorde uitgelegd waarin je ze kunt uitproberen. Animaties zijn een andere vaak voorkomende bron van problemen, dus overweeg ze uit te schakelen in testomgevingen.

Oorzaak 5: Externe diensten en netwerken

Als een test een echte betalingsprovider of een API van derden aanroept, hangt het resultaat af van de uptime en tarieflimieten van iemand anders. Bespot deze oproepen voor de meeste tests en houd een klein aantal afzonderlijke contractcontroles bij ten opzichte van de echte service, zodat u nog steeds leert of deze verandert. In onze gids voor unit- versus integratietests wordt uitgelegd hoe u deze kunt opsplitsen.

Hoe een schilferige test te diagnosticeren

1. Bevestig het. Voer de test vele malen uit zonder wijzigingen. Met pytest werkt een eenvoudige shell-loop, en een plug-in zoals pytest-repeat geeft je --count=100.
2. Bewijsmateriaal vastleggen. Bewaar logboeken, schermafbeeldingen en sporen voor elke fout. De sporenviewer van Toneelschrijver is hier bijzonder nuttig.
3. Benadruk de omstandigheden. Voer het uit met een beperkte CPU, parallel of in willekeurige volgorde. Door vaker te falen, kun je makkelijker studeren.
4. Test het alleen. Als het altijd alleen lukt, maar mislukt in de suite, vermoed dan een gedeelde status.
5. Zoek naar patronen. Controleer om welke machines, tijdstippen en aangrenzende tests het gaat.
6. Controleer het product. Vraag eerlijk of dit in uw toepassing een echte raceconditie kan zijn.

Zijn automatische nieuwe pogingen een oplossing?

Nieuwe pogingen zijn een nuttig vangnet voor de korte termijn, maar geen remedie. Eén enkele automatische nieuwe poging in CI kan het werk gaande houden terwijl u onderzoek doet, maar een test waarvoor een nieuwe poging nodig is om te slagen, vertelt u nog steeds iets. Erger nog, een echte periodieke productbug die 20% van de tijd mislukt, zal een nieuwe poging meestal onopgemerkt doorstaan.

Gebruik nieuwe pogingen met deze regels: beperk ze tot één of twee, noteer elke test waarvoor er één nodig was, en behandel die lijst als uw takenlijst. Een test die wordt gerapporteerd als ‘doorgegeven bij nieuwe poging’ moet gelden als een probleem dat moet worden onderzocht, en niet als een succes.

Een teamproces voor zwakke tests

1. Meten. Houd bij welke tests mislukken en geef vervolgens dezelfde commit door. Veel CI-tools en testreporters kunnen dit aantonen.
2. Quarantaine. Verplaats een bevestigde zwakke test uit de blokkeringsrun, zodat deze niet langer iedereen stoort, maar blijf hem uitvoeren en volgen.
3. Wijs een eigenaar en een deadline toe. Een quarantaine zonder deadline wordt gewoon een kerkhof.
4. Repareren of verwijderen. Als een test het niet waard is om deze te corrigeren, verwijder deze dan en controleer of de dekking elders nog steeds bestaat.
5. Voorkomen. Voer meerdere keren nieuwe tests uit voordat u samenvoegt. Een test die één keer op de vijftig runs mislukt, kun je beter nu oppakken dan over een half jaar.

Behandel een slechte test als een bug met prioriteit, en niet als achtergrondgeluid. Ernst en prioriteit zijn hier ook van toepassing, zoals beschreven in ernst versus prioriteit. Als er sprake is van een wijdverbreid probleem, lees dan meer over de bredere fouten in de testautomatisering en overweeg of u te veel tests op browserniveau heeft.

Tot slot

Schilferige tests voelen willekeurig aan, maar dat zijn ze zelden. Bijna iedereen komt neer op een aanname over tijd, orde, data of omgeving die niet altijd waar is. Kies de test die deze week het vaakst mislukt in uw pijplijn. Voer het vijftig keer uit, vind de aanname en herstel dat voorgoed. Eén echte oplossing leert een team meer dan honderd herhalingen ooit zullen doen.

Veelgestelde vragen

Blijf leren