Apex-testfouten en codedekkingsfouten in Salesforce-deployments oplossen

Productie-deployments vereisen geslaagde Apex-tests en minimaal 75% codedekking, en Salesforce blokkeert de release totdat aan beide is voldaan.

Komt voor bij: deployment naar productie of een volledige sandbox-refresh

Wat het betekent

Salesforce vereist dat deployments naar productie Apex-tests uitvoeren en een gemiddelde codedekking van minstens 75% behalen over alle classes en triggers, waarbij elke trigger enige dekking nodig heeft. Een deployment mislukt, met een overzicht van de assertion of exception van elke mislukte test, zodra een test een onafgehandelde exception gooit, een assertion faalt, of de gemiddelde dekking van de org onder die drempel zakt.

Dit gate alleen deploys naar productie en volledige sandboxes met RunLocalTests of RunAllTestsInOrg; deploys naar Developer sandboxes of scratch orgs met NoTestRun slaan de vereiste volledig over, wat precies de reden is waarom dekkingshiaten pas op de releasedag worden opgemerkt.

Diagnose

Veelvoorkomende oorzaken

Een test doet een assertion op data die door niet-gerelateerde code is gewijzigd
Een nieuw gedeployde trigger of Flow wijzigt een veld waarop de test een assertion doet, waardoor de verwachte waarde van de test niet langer overeenkomt, ook al is de test zelf niet aangepast.
Nieuwe code uitgebracht zonder bijbehorende tests
Een class of trigger is toegevoegd of uitgebreid zonder bijbehorende testmethode, waardoor de gemiddelde dekking van de org onder de 75% zakt.
Test is afhankelijk van org-specifieke data of configuratie
De test bevraagt bestaande records, record types of settings in plaats van eigen data aan te maken, waardoor deze slaagt in de ene org en faalt in een andere waar die data niet bestaat.

De oplossing

  1. Reproduceer de fout eerst lokaal
    Voer de volledige lokale testsuite met dekking uit tegen je sandbox voordat je de code aanraakt, zodat je de echte fout debugt en niet een verouderd deploylog.
    sf apex run test --test-level RunLocalTests --code-coverage --result-format human --wait 20
  2. Schrijf tests voor nieuwe code voordat je deployt
    Voeg testmethoden toe die nieuwe classes en triggers uitoefenen, zodat de gemiddelde dekking van de org vóór de release boven de 75% uitkomt.
  3. Maak tests zelfstandig
    Herschrijf tests zodat ze hun eigen testdata aanmaken met @TestSetup of Test.startTest(), in plaats van te vertrouwen op records die toevallig in de doel-org bestaan.
In de praktijk

Hoe Serpent dit voorkomt

De VS Code-extensie van Serpent toont testresultaten en dekking direct op de taak zelf, zodat een dekkingshiaat of mislukte assertion zichtbaar is voordat een taak wordt ingediend, in plaats van pas tijdens een productie-deploy te worden ontdekt. Zie de Salesforce-deploymentfoutenbibliotheek.

Releases
Taken
Orgs
v2.8.3 · Productie
Componenten
AccountTrigger
OpportunityFlow
DashboardLWC
PermissionSet_A
EmailTemplate
0 van 5 gereed
Serpent AI-review
Analyseren…
Geen breaking changes
Testdekking: 94%
Afhankelijkheden in kaart
Delta gevalideerd
Wachten op AI-review…
✓ Geïmplementeerd naar productie · zojuist

Preventie

Blokkeer merges op basis van dekking, niet alleen slagen/falen
Laat CI falen bij elke pull request die de org-brede dekking onder 75% brengt, niet alleen bij een harde testfout, zodat het hiaat nooit een release bereikt.
Doe nooit een assertion op recordaantallen zonder WHERE-scoping
Scope elke assertion-query naar de records die de test zelf heeft aangemaakt, zodat later toegevoegde, niet-gerelateerde automatisering de assertion niet stilletjes kan breken.
Voer een RunLocalTests-validatie uit vóór elke productierelease
Start een check-only deploy met RunLocalTests vóór de daadwerkelijke release, zodat fouten op tijd aan het licht komen om te herstellen, niet tijdens het deploymentvenster.
Veelgestelde vragen

APEX TEST FAILURES, beantwoord

Garandeert 75% dekking dat een deployment slaagt?
Nee. Dekking is een minimumdrempel, geen kwaliteitsmaatstaf. Elke test moet nog steeds daadwerkelijk slagen; een suite kan 75% dekking behalen en de deployment toch laten mislukken als zelfs één test een onafgehandelde exception of een mislukte assertion oplevert.
Heeft elke afzonderlijke class 75% dekking nodig?
Nee, de drempel van 75% is een org-breed gemiddelde. Individuele classes mogen eronder zitten zolang het algemene gemiddelde de lat haalt, al heeft elke trigger nog steeds enige dekking nodig.
Waarom faalt een test die nooit is gewijzigd plotseling?
Iets anders in dezelfde transactie is veranderd: een nieuwe trigger, Flow of validation rule raakt nu data aan waarop de test een assertion doet. Controleer wat er nog meer is gedeployd naast de mislukte test.

Start gratis. Geen creditcard, geen installatie, geen verplichting.

Binnen 15 minuten ingesteld. Geen DevOps-aanwerving nodig.

Benieuwd naar sneller releasen voordat je instapt? Laten we praten

Vrijblijvend.