Apex-tests parallel draaien zonder flaky failures

Om Apex-tests parallel te draaien zonder flaky failures laat je elke test zijn eigen data aanmaken, schrijf je nooit naar records die buiten de test bestaan en genereer je unieke waarden voor velden zoals gebruikersnamen. Onderzoek een resterende flaky test door die klasse apart opnieuw te draaien: slaagt hij alleen en faalt hij parallel, dan heb je een isolatieprobleem, geen bug. Parallel testen org-breed uitzetten verbergt het symptoom en vertraagt elke run.

Waarom falen Apex-tests alleen als ze parallel draaien?

Standaard draait Salesforce asynchrone testklassen gelijktijdig, waardoor twee tests op hetzelfde moment om dezelfde resource kunnen strijden. De fouten vallen in drie oorzaken uiteen:

• Strijd om recordlocks. Een transactie die op een gelockt record wacht, krijgt 10 seconden voordat Salesforce UNABLE_TO_LOCK_ROW teruggeeft, en die limiet is niet aan te passen, zoals Xappex uitlegt. Parent-records worden stilletjes gelockt bij updates van master-detail-children, bij herberekening van roll-up summaries en tijdens sharingverwerking.
• Org-brede unieke waarden. Gebruikersnamen zijn uniek binnen heel Salesforce, dus twee klassen die tegelijk [email protected] invoegen falen met DUPLICATE_USERNAME, een patroon dat Salesforce Central beschrijft.
• Gedeelde org-data. Een test met @isTest(SeeAllData=true) leest en schrijft echte records die andere tests tegelijk kunnen raken.

Geen van deze problemen verschijnt als een klasse alleen draait, en daarom lijkt de suite willekeurig te falen.

Hoe onderscheid je een parallelle flake van een echte bug?

1. Lees de foutmelding. UNABLE_TO_LOCK_ROW, DUPLICATE_USERNAME en andere duplicate-value-fouten op testdata wijzen op gelijktijdigheid.
2. Draai de klasse apart. De Salesforce CLI-vlag --synchronous draait de testmethodes van één Apex-klasse synchroon, volgens de documentatie van plugin-apex.
3. Vergelijk. Slaagt alleen, faalt parallel: isolatieprobleem. Faalt in beide gevallen: een echt defect. Repareer het, probeer het niet opnieuw.
4. Leg het vast. Noteer klasse, fout en datum. Een klasse die twee keer per maand flaky is, gaat bovenaan de fixlijst.

Hoe maak je Apex-tests veilig voor parallelle uitvoering?

1. Maak alle testdata in de test zelf aan. Gebruik @TestSetup of een data factory en schrap SeeAllData=true. Tests die hun eigen data bouwen, strijden niet om org-records.
2. Schrijf alleen naar de eigen records van de test. Vermijd updates van gedeelde setup-records, de uitvoerende gebruiker of alles wat een sharingherberekening kan locken.
3. Maak unieke velden uniek per klasse. Geef gebruikersnamen en andere unieke waarden een prefix met de naam van de testklasse plus een willekeurig getal.
4. Scheid unit tests van integratietests. Logica die je zonder DML kunt testen, neemt nooit een lock. Houd de zware, datagebonden tests in een kleinere set die je goed in de gaten houdt.
5. Markeer bewezen klassen. Winter '18 voegde @isTest(isParallel=true) toe om klassen te markeren die parallel kunnen draaien zonder de standaardlimieten voor gelijktijdigheid, zoals FishOfPrey beschrijft. Voeg het alleen toe aan klassen die herhaaldelijk slagen in parallelle runs.

Moet je gewoon Disable Parallel Apex Testing aanzetten?

Alleen als noodoplossing. De instelling staat onder Setup, Apex Test Execution, Options, en draait asynchrone tests één voor één. Dat haalt de gelijktijdigheidsflakes weg, maar in orgs met veel testklassen duurt een volledige run veel langer. Sommige tools leunen op dezelfde schakelaar: de documentatie van Gearset meldt dat de test monitors de Tooling API gebruiken en tests dus parallel draaien, tenzij je de instelling aanzet.

Zie het vinkje als een schuldmarkering. Zet het aan om een release vrij te spelen, repareer daarna de boosdoeners en zet het weer uit.

Hoe draai je parallelle Apex-tests betrouwbaar in CI?

• Draai standaard asynchroon. sf apex run test --test-level RunLocalTests geeft je dezelfde parallelle run die je productiedeploys zien.
• Leg resultaten machineleesbaar vast. Voeg --result-format junit --output-dir toe zodat je pipeline fouten per klasse over tijd volgt, en --code-coverage om de dekking zichtbaar te houden.
• Eerst classificeren, dan één keer opnieuw. Draai alleen fouten met een gelijktijdigheidssignatuur synchroon opnieuw. Slaagt de herhaling, log dan een flake; faalt hij, laat de build dan falen.
• Volg de flake rate. Een stijgend aantal is een probleem in je testontwerp, niet in het platform.

Blind opnieuw proberen is verleidelijk, maar maakt van echte defecten groene builds. Dezelfde discipline geldt als je van tooling wisselt, zoals beschreven in overstappen op een andere Salesforce DevOps-tool zonder je pipeline te breken en onze gids over migreren van Gearset naar Serpent zonder downtime.

Point-and-click-releases lopen tegen dezelfde fouten aan, omdat de tests bij een deploy nog steeds draaien. Onze click-deploy-checklist beschrijft wat je eerst controleert, en meer how-to's vind je in SF Guides.

Wie is Tekunda?

Tekunda is het Salesforce-consultancy- en productbedrijf dat Serpent bouwt, een Salesforce DevOps-platform met versiebeheer via GitHub en geautomatiseerde deploymentpipelines. Houden flaky tests je releases op, vergelijk dan de abonnementen op onze prijspagina.

FAQ

Draait Salesforce Apex-tests standaard parallel?

Ja, asynchrone testruns voeren klassen gelijktijdig uit, tenzij Disable Parallel Apex Testing in Setup aanstaat.

Wat veroorzaakt UNABLE_TO_LOCK_ROW in Apex-tests?

Twee transacties willen hetzelfde record, vaak een parent die gelockt is door een master-detail-update, roll-up summary of sharingherberekening. De wachtende transactie faalt na 10 seconden.

Moet ik flaky Apex-tests automatisch opnieuw draaien?

Eén keer, synchroon, en alleen bij gelijktijdigheidsfouten. Log elke flake en repareer de klasse in plaats van op herhalingen te vertrouwen.

Is isParallel=true genoeg om flaky tests op te lossen?

Nee. Het markeert een klasse alleen als geschikt voor parallelle uitvoering. De test moet nog steeds zijn eigen data maken en unieke waarden gebruiken.