Zo bouw je een Salesforce-testautomatiseringspipeline in CI

Een Salesforce-testautomatiseringspipeline draait je Apex- en Lightning Web Component-tests automatisch bij elke commit, voordat code de productie bereikt. Een werkende opzet koppelt een git-repository aan een CI-runner, start een scratch org of sandbox, deployt de metadata, draait de tests en laat de build falen als de coverage onder de 75 procent zakt die Salesforce vereist. Deze gids doorloopt de hele pipeline, van eerste testniveau tot de valkuilen die teams vertragen.

Wat is Salesforce-testautomatisering in CI?

Continuous integration (CI) is de praktijk om elke wijziging te valideren zodra die binnenkomt, in plaats van bij een release-poort. Voor Salesforce betekent dat een pipeline die je geautomatiseerde tests draait bij elke push of pull request en de merge blokkeert als iets faalt. Het doel is shift-left testen: een kapotte trigger of falende assertion binnen minuten op een branch vangen, niet tijdens een releaseavond in productie.

Salesforce hanteert een harde regel die dit onmisbaar maakt: voordat je Apex naar productie kunt deployen, moeten je tests slagen en heb je minstens 75 procent code coverage nodig. CI is hoe je dat continu groen houdt in plaats van te improviseren bij de deploy.

Wat moet je bij elke commit testen?

Een bruikbare Salesforce-suite is gelaagd. Streef ernaar te dekken, snelste eerst:

• Apex-unittests: de ruggengraat. Dek triggers, classes en businesslogica met betekenisvolle assertions, niet enkel coverage-opvulling.
• LWC Jest-tests: componentlogica voor Lightning Web Components, gedraaid met @salesforce/sfdx-lwc-jest. Deze zijn snel en draaien zonder org.
• Integratie- en smoke-tests: een dunne laag die na de deploy de kritieke end-to-end-paden en externe integraties controleert.

Draai Apex en Jest bij elke commit omdat ze snel zijn, en bewaar tragere UI-end-to-end-checks voor een nachtelijke fase. Onze gids over wat je per pull request draait en wat 's nachts werkt die splitsing uit.

Hoe zet je een CI-pipeline op voor Salesforce-tests?

De onderdelen zijn hetzelfde of je nu GitHub Actions, GitLab CI of Jenkins gebruikt. Een minimale pipeline doet dit bij elke pull request:

1. Authenticeer de Salesforce CLI bij een Dev Hub, meestal met een JWT-authflow en een opgeslagen certificaat.
2. Maak een omgeving: start een scratch org (of richt je op een dedicated CI-sandbox).
3. Deploy de source met sf project deploy start.
4. Draai tests met sf apex run test --test-level RunLocalTests --code-coverage --result-format human, en draai npm run test:unit voor LWC Jest.
5. Blokkeer de build op het resultaat en verwijder daarna de scratch org zodat er niets blijft hangen.

Salesforce publiceert een officiele uitleg over Salesforce DX met GitHub Actions die netjes op deze stappen aansluit.

Welk Apex-testniveau moet CI gebruiken?

Het testniveau bepaalt hoeveel er draait en hoe lang de build duurt:

• RunLocalTests draait elke test in de org behalve die uit geïnstalleerde managed packages, en is de veilige standaard voor een validatiepipeline.
• RunSpecifiedTests draait alleen genoemde classes, handig voor snelle branch-feedback maar riskant als productiepoort omdat het coverage kan missen.
• Een nieuwer niveau RunRelevantTests verscheen in beta in de Spring '26-release om deploys te verkorten door alleen de tests te draaien die door een wijziging worden geraakt; behandel het als beta tot je het tegen je suite hebt gevalideerd.

Kies voor de merge-blokkerende build bij voorkeur RunLocalTests zodat de coverage echt is. Gebruik specified of relevant tests alleen voor snelle, niet-blokkerende feedback eerder in de branch.

Waar gaat het mis met Salesforce CI?

Drie fouten verklaren de meeste vastgelopen pipelines:

Jagen op het getal van 75 procent in plaats van echte assertions. Coverage zonder assertions haalt de poort en levert toch bugs.

De andere twee zijn onbetrouwbare testdata en een suite die te traag wordt om bij elke commit te draaien. Los de eerste op door testdata binnen elke test aan te maken met een factory-patroon en @testSetup, en nooit op org-data te leunen. Los de tweede op door snelle unittests te scheiden van trage end-to-end-tests, zodat feedback onder een paar minuten blijft waar het het meest telt. Tooling uit de Salesforce DevOps-categorie, waaronder Copado, Gearset, Salto, AutoRABIT, Flosum en Blue Canvas, kan deze stappen in een beheerde pipeline verpakken als je de YAML liever niet met de hand bouwt.

Voor meer Salesforce DevOps-handleidingen, zie onze resourcesbibliotheek.

FAQ

Welke code coverage vereist Salesforce om te deployen?

Minstens 75 procent org-brede Apex-coverage, en elke test moet slagen. CI houdt dit continu groen in plaats van een tekort te ontdekken bij de deploy.

Heb ik scratch orgs nodig voor Salesforce CI?

Nee, maar ze helpen. Scratch orgs geven elke build een schone, wegwerpbare omgeving. Een dedicated CI-sandbox werkt ook als source tracking en reset zorgvuldig worden beheerd.

Hoe test ik Lightning Web Components in CI?

Gebruik de Jest-gebaseerde runner @salesforce/sfdx-lwc-jest. Die draait componenttests lokaal zonder org, snel genoeg voor elke commit.

Welke CI-tool is het beste voor Salesforce?

GitHub Actions, GitLab CI en Jenkins werken allemaal goed met de Salesforce CLI. De runner telt minder dan een schone pipeline: authenticeren, deployen, tests draaien, blokkeren, opruimen.