Salesforce-testautomatisering in CI: wat draai je per pull request en wat 's nachts?

Kort antwoord: draai op elke pull request alleen de snelle en deterministische checks: statische analyse op de diff, LWC Jest, en een validate-only deltadeployment die alleen de Apex-tests draait die de gewijzigde code dekken. Zet alles wat traag of instabiel is, volledige org-testruns, UI-scenario's en externe integraties, in een nachtelijke job. Mik op een uitslag binnen tien minuten, want daarna leest niemand hem nog.

Wat hoort op elke pull request?

• Statische analyse op de diff. Seconden, geen org nodig, vangt de mechanische fouten voordat een mens de code leest.
• LWC Jest-tests. Ze draaien buiten het platform in Node en hebben dus helemaal geen org nodig.
• Een validate-only deltadeployment tegen een org die op het doel lijkt, met een testniveau dat alleen de klassen draait die het gewijzigde dekken.
• Metadatacontroles. Geen onbedoelde destructive changes, geen profiel- of permission set-regels die stilletjes verdwijnen.

Eén regel beheerst deze lijst: alles op de PR-poort moet deterministisch zijn. Eén instabiele test leert het team op opnieuw uitvoeren te drukken, en een poort die mensen net zo lang herhalen tot hij groen is, is decoratie.

Wat hoort in de nachtelijke job?

• Een volledige lokale Apex-run tegen de integratiesandbox. Dat vangt de klasse waarvan je niet wist dat je wijziging hem raakte.
• UI-scenario's over de kernprocessen.
• Integratietests die externe systemen aanroepen, waar je latentie of beschikbaarheid niet in de hand hebt.
• Een driftcontrole tussen de integratie-org en de branch, zodat wie direct in Setup werkt de volgende ochtend zichtbaar is.
• De dekkingstrend op orgniveau, als rapport en niet als poort.

Nachtelijke fouten worden bij de koffie getrieerd. Dat is precies de bedoeling: ze staan niet tussen een developer en zijn merge.

Wat draait alleen vóór een release?

• De volledige regressiesuite en een eventuele acceptatieronde.
• Performance- en bulkdatatests, die volume nodig hebben dat een scratch org niet heeft.
• Een validate-only deployment tegen productie, gevolgd door een quick deploy, zodat het releasevenster niet opgaat aan wachten op tests.

Hoe passen de Salesforce-testniveaus hierop?

Vier niveaus, en de keuze per fase is het grootste deel van het ontwerp (Metadata API-gids).

• NoTestRun: prima binnen een scratch org, nooit op een pad naar productie.
• RunSpecifiedTests: je PR-poort. Eén valkuil is het weten waard: op dit niveau moet elke klasse en trigger in het pakket afzonderlijk 75% dekking halen, per component berekend en niet org-breed (Salesforce-documentatie).
• RunLocalTests: alles behalve tests uit managed packages. Dit draait standaard bij een productiedeployment met Apex erin.
• RunAllTestsInOrg: inclusief managed package-tests. Zelden wat je wilt, en traag.

De platformregels eronder veranderen niet: minstens 75% van je Apex moet gedekt zijn om naar productie te deployen, elke trigger heeft minstens één gedekte regel nodig, en elke test die draait moet slagen, wat het dekkingspercentage ook zegt (Salesforce Help).

Hoe houd je de PR-lus onder tien minuten?

1. Deploy de delta, niet de org. Valideer alleen wat de branch heeft gewijzigd.
2. Leid de testlijst af. Genereer de opgegeven testklassen uit de gewijzigde componenten in plaats van een handmatig onderhouden lijst.
3. Draai parallel. Jest en statische analyse horen naast de org-validatie te lopen, niet erachter in de wachtrij.
4. Houd een warme doel-org. Een org per pull request aanmaken en vullen is meestal het grootste blok kloktijd. Gebruik een pool of een langlevende validatiesandbox.
5. Cache afhankelijkheden tussen runs, inclusief de CLI en Node-modules.
6. Stub of verplaats externe calls. Alles waarvan je de responstijd niet beheerst, hoort in de nachtelijke job.
7. Meet de doorlooptijd en zet hem ergens zichtbaar. Pipelineduur kruipt stilletjes omhoog, altijd maar één kant op.

Waar horen UI-tests?

Niet op de pull request. UI-tests zijn het traagste en broosste onderdeel van een Salesforce-pipeline: shadow DOM in Lightning-componenten, gegenereerde element-id's en inlogprompts breken selectors om redenen die niets met de beoordeelde wijziging te maken hebben.

Wat wel werkt: een kleine smoke-set van vijf tot tien kritieke scenario's na de merge naar de integratiebranch, en de volledige suite 's nachts. Praktische regel: faalt een UI-test twee keer om andere redenen dan het product, dan is het onderhoud en geen poort.

Hoe stel je dekkingspoorten in?

• Beoordeel de PR op dekking van de gewijzigde code, niet op het org-brede getal. Dat getal beweegt traag en verstopt splinternieuwe ongeteste klassen achter jaren oude.
• Houd de org-brede ondergrens als releasepoort, waar hij thuishoort.
• Maak het percentage niet tot doel. Salesforce adviseert zelf om elke use case te dekken, positief en negatief, bulk en enkel record, en het getal te laten volgen.

Deze gids maakt deel uit van onze Salesforce DevOps-gidsen.

FAQ

Hoe snel moet een Salesforce-PR-check zijn?

Onder de tien minuten van begin tot eind. Daarna schakelen developers om, lezen ze de uitvoer niet meer, en verandert de check geen gedrag meer.

Moeten we alle Apex-tests op elke pull request draaien?

Nee. Draai de tests die de gewijzigde klassen dekken met RunSpecifiedTests, en houd de volledige lokale run voor de nachtelijke job en de releasevalidatie.

Welke dekking vereist Salesforce echt?

75% van je Apex org-breed om naar productie te deployen, minstens één gedekte regel per trigger, en elke uitgevoerde test moet slagen. Bij RunSpecifiedTests heeft elke klasse en trigger in het pakket afzonderlijk 75% nodig.

Hebben LWC Jest-tests een Salesforce-org nodig?

Nee. Ze draaien buiten het platform in Node, en precies daarom horen ze op de PR-poort en niet in de nachtelijke job.

Waar horen UI-tests te draaien?

Een kleine smoke-set na de merge, de volledige suite 's nachts. Ze op de pull request zetten is de snelste manier om een team te leren een rode build te negeren.