Salesforce-Qualität: Tests, Reviews und Quality Gates

Jede Salesforce-Änderung sollte vor dem Merge dieselben Prüfungen bestehen, und jede Prüfung muss technisch sperren können. Dazu gehören ein Pflicht-Review durch einen Menschen, ein Validierungs-Deployment mit Apex-Tests, die mehr beweisen als 75 Prozent Abdeckung, Flow-Tests für die wichtigsten Automatisierungen und statische Analyse mit Salesforce Code Analyzer samt Schwellenwert. Die Regeln, Schwellen und Ausnahmen legt der Kunde fest, für jeden Partner gleich. sfdx-hardis liefert diese Gates als Open Source, Gearset, Copado und Flosum als kommerzielle Plattform. Für KI-generierten Code gelten dieselben Gates, ohne Ausnahme.

Was ist ein Quality Gate in einer Salesforce-Pipeline?

Ein Quality Gate ist eine automatische oder menschliche Prüfung, die eine Änderung aufhält, bis sie bestanden ist. Entscheidend ist das Aufhalten: Ein Bericht über 300 Funde, der den Merge nicht sperrt, ändert am Release nichts. In Kapitel 5 haben Sie gesehen, wie ein Pull Request durch die Pipeline läuft und welches Apex-Testlevel wohin gehört. Dieses Kapitel klärt, was an den einzelnen Stationen geprüft wird und wer die Messlatte setzt.

Ich ordne Gates nach Kosten. Günstige Prüfungen laufen zuerst und scheitern schnell, teure kommen danach:

1. 01

   Statische Analyse

   Laufzeit in Minuten

   Apex, Lightning Web Components und Flows prüfen.

2. 02

   Validierungs-Deployment

   Gegen die Zielorg, mit Apex-Tests und Abdeckung.

3. 03

   Flow-Tests

   Für die kritischen Automatisierungen.

4. 04

   Review

   Durch einen Menschen, der nur noch Änderungen sieht, die die Schritte 1 bis 3 bestanden haben.

Die Sperre selbst setzt Ihre Git-Plattform. Auf GitHub verlangt ein geschützter Branch laut Dokumentation (öffnet in einem neuen Tab) eine festgelegte Zahl von Freigaben und bestandene Status Checks. Zwei Optionen würde ich in jedem Programm mit mehreren Partnern einschalten: Freigaben verfallen, wenn danach neue Commits kommen, und „Do not allow bypassing the above settings“, denn ohne diese Option gelten die Regeln nicht für Administratoren. Haben Partner Admin-Rechte im Repository, ist der Branch-Schutz sonst eine Empfehlung.

Warum sind Reviews Pflicht, auch mit guter Automatisierung?

Werkzeuge prüfen Regeln. Ob eine Änderung zur Architektur passt, ob ein neues Feld wirklich gebraucht wird oder ob ein Trigger mit dem Flow eines anderen Teams kollidiert, sieht nur ein Mensch, der die Org kennt. Deshalb ist für mich jeder Pull Request ohne Freigabe gesperrt, ausnahmslos. Die Begründung und wie Sie Reviews einführen, ohne langsamer zu werden, steht in warum Pull-Request-Reviews Pflicht sind.

Für die Rollen aus Kapitel 2 heißt das konkret:

• Partner reviewen sich gegenseitig bei Änderungen innerhalb ihres Bereichs.
• Der Architekt auf Kundenseite gibt frei, was Datenmodell, Sharing, Permission Sets oder Schnittstellen zu SAP berührt. Auf GitHub erzwingen Sie das mit Code Ownern: Eine Datei mit Code Owner braucht dessen Freigabe.
• Der Release Manager verantwortet Schwellenwerte und Regelsätze und ist der Einzige, der sie ändert.

Flows, Page Layouts und Permission Sets gehören genauso ins Review wie Apex. Gerade in Service- und Field-Service-Orgs steckt ein großer Teil der Geschäftslogik in Flows, die Admins der Partner bauen. Ein Review, das nur Code ansieht, übersieht diese Hälfte.

Apex-Tests: warum 75 Prozent nur die Untergrenze sind

Für ein Deployment nach Produktion verlangt Salesforce laut Apex Developer Guide (öffnet in einem neuen Tab), dass Tests mindestens 75 Prozent des Apex-Codes abdecken, alle Tests bestehen und jeder Trigger etwas Abdeckung hat. Dieselbe Dokumentation sagt in den Testing Best Practices (öffnet in einem neuen Tab) aber auch: „don’t focus on the percentage of code that is covered.“ Abdeckung misst, welche Zeilen gelaufen sind, nicht, ob das Ergebnis stimmt.

Was ich stattdessen in der Definition of Done sehen will, steht fast wörtlich im selben Leitfaden:

• Echte Asserts mit den Methoden der Assert-Klasse, die fachliches Verhalten prüfen.
• Positiv- und Negativfälle, gültige und ungültige Eingaben.
• Bulk-Tests mit mindestens 20 Datensätzen, damit ein Trigger beim nächtlichen Import der Auftragsstände aus SAP nicht an Governor Limits scheitert.
• Tests mit runAs in verschiedenen Benutzerkontexten, etwa als Servicetechniker oder Händler im Portal.
• Eigene Testdaten statt Daten aus der Org, damit Tests nach einem Sandbox-Refresh noch laufen.

75 %

Apex-Abdeckung, die Salesforce für ein Deployment nach Produktion mindestens verlangt

20

Datensätze mindestens in jedem Bulk-Test

80 bis 90 %

strengere Grenze, die sfdx-hardis für saubere Projekte empfiehlt

Den maschinell prüfbaren Teil davon erzwingen PMD-Regeln aus der Kategorie Best Practices (öffnet in einem neuen Tab): ApexUnitTestClassShouldHaveAsserts verlangt mindestens einen Assert, ApexUnitTestShouldNotUseSeeAllDataTrue verbietet den Zugriff auf Org-Daten, ApexUnitTestClassShouldHaveRunAs verlangt mindestens ein runAs. Die erste Regel besteht auch ein Test, der nur auf „nicht null“ prüft. Ob ein Assert etwas beweist, bleibt Aufgabe des Reviews.

Die Abdeckungsgrenze selbst können Sie anheben. In sfdx-hardis heißt der Parameter apexTestsMinCoverageOrgWide (öffnet in einem neuen Tab), Standard 75, und die Dokumentation empfiehlt für saubere Projekte strengere Werte wie 80 oder 90. In einer gewachsenen Org mit Jahren an Altcode würde ich die Grenze für neue und geänderte Klassen anheben und die Gesamtabdeckung schrittweise nachziehen. Ein Sonderfall ist API-Version 67.0: Apex läuft dort standardmäßig im User Mode, und ein Test ohne runAs sieht nicht, welche Datensätze ein eingeschränkter Benutzer verliert. Details in API 67.0: warum Apex weniger Datensätze sieht.

Wie testen Sie Flows?

Flows sind in vielen Fertigungs-Orgs die größere Automatisierung: Statuswechsel im Serviceauftrag, Eskalationen bei Garantiefällen, Benachrichtigungen an Händler. Trotzdem laufen sie in vielen Pipelines ungeprüft durch. Drei Werkzeuge gibt es:

Flow-Tests. Für record-triggered, autolaunched und Data-Cloud-triggered Flows lassen sich laut Metadata API Developer Guide (öffnet in einem neuen Tab) Tests anlegen, die erwartete Ergebnisse prüfen. Sie liegen als Metadatentyp FlowTest im Repository. Die Salesforce CLI führt sie mit sf flow run test (öffnet in einem neuen Tab) aus, Ergebnisse auch im JUnit-Format für die Pipeline; sf logic run test führt Flow- und Apex-Tests zusammen aus. Ein praktisches Detail: Der ausführende Benutzer braucht die Berechtigung „View All Data“. Das betrifft den technischen Benutzer Ihrer Pipeline.

Abdeckung für aktiv deployte Flows. Standardmäßig kommen Flows, die in der Sandbox aktiv sind, laut Salesforce Help (öffnet in einem neuen Tab) inaktiv in Produktion an und müssen von Hand aktiviert werden. Mit der Einstellung „Deploy processes and flows as active“ in den Process Automation Settings legen Sie eine Abdeckungsgrenze fest. Sie gilt für Prozesse und autolaunched Flows, die per Change Set oder Metadata API deployt werden, und gemessen wird sie über Apex-Tests: Mindestens ein Apex-Test muss die eingestellte Abdeckung der aktiven Prozesse und autolaunched Flows erreichen. Flows mit Screens sind von der Anforderung ausgenommen. Die Werte stehen im Tooling-API-Objekt FlowTestCoverage (öffnet in einem neuen Tab). Für eine Pipeline, die auch nach Produktion ohne Handarbeit deployen soll, ist diese Einstellung der saubere Weg.

Statische Analyse von Flows. Der Flow Scanner in Code Analyzer findet typische Baufehler in Flows, bevor überhaupt ein Test läuft.

Meine Empfehlung: Jeder record-triggered Flow auf einem Kernobjekt wie Arbeitsauftrag, Anlage oder Garantiefall bekommt mindestens einen Flow-Test für den Hauptpfad und einen für den wichtigsten Fehlerfall. Screen Flows testen Sie weiterhin fachlich in UAT.

Statische Analyse mit Salesforce Code Analyzer

Salesforce Code Analyzer (öffnet in einem neuen Tab) bündelt in Version 5 acht Engines, alle standardmäßig aktiv. Für Ihre Pipeline zählen vor allem diese:

Engine	Prüft	Typischer Fund
PMD	Apex und Visualforce	SOQL in Schleifen, fehlende Sharing-Deklaration, Tests ohne Assert
ESLint	JavaScript in Lightning Web Components	unsichere Muster, Fehler im Komponentencode
Flow Scanner	Flows	Datenbankzugriffe in Schleifen, fehlende Fehlerpfade, fest codierte IDs
Salesforce Graph Engine	tiefere Analyse von Apex über Aufrufpfade	Sicherheitslücken, die erst über mehrere Klassen sichtbar werden
Regex	eigene Muster aus code-analyzer.yml	fest codierte Endpunkte statt Named Credential
CPD	doppelten Code	kopierte Logik in mehreren Handlern

Die Regeln des Flow Scanners (öffnet in einem neuen Tab) sind für Admins der Partner besonders nützlich: DbInLoop meldet Get-, Create-, Update- und Delete-Elemente in Schleifen, MissingFaultHandler Elemente ohne Fehlerpfad, HardcodedId org-spezifische IDs, die beim Deployment brechen. Zwei Regeln melden, wenn Benutzereingaben in einem Flow im Systemkontext Datensätze auswählen oder ändern, ein Risiko für Rechteausweitung.

In der Pipeline rufen Sie sf code-analyzer run auf oder die GitHub Action. Laut CI/CD-Leitfaden (öffnet in einem neuen Tab) muss es Version 2 der Action sein, Version 1 nutzt den abgekündigten Code Analyzer v4. Ohne --rule-selector läuft der Regelsatz Recommended.

In einer Org mit zehn Jahren Apex würde ich ab „High“ blockieren und den Rest berichten. Wer am ersten Tag alles blockiert, bekommt Hunderte Altfunde, und Partner fangen an, Regeln abzuschalten statt Code zu korrigieren. Die Schwelle senken Sie, sobald der Bestand aufgeräumt ist; wie Sie technische Schulden vorher sichtbar machen, beschreibe ich in Kapitel 9.

Wie laufen die Gates in sfdx-hardis und in kommerziellen Werkzeugen?

Alle Werkzeuge aus Kapitel 4 decken die Gates ab, mit unterschiedlicher Bedienung.

sfdx-hardis, das ich seit rund zwei Jahren in Kundenprojekten einsetze, startet laut Dokumentation (öffnet in einem neuen Tab) bei jedem Pull Request zwei Kontrolljobs. Der erste simuliert das Deployment in der Zielorg, führt die Apex-Tests aus, berechnet die Abdeckung und schreibt das Ergebnis mit einem visuellen Diff geänderter Flows in den Pull Request. Der zweite führt MegaLinter mit PMD für Apex, ESLint für Lightning Web Components, einer Suche nach fest codierten Tokens und einer Copy-Paste-Erkennung aus. Gemergt wird laut Dokumentation nur, wenn beide grün sind. Die MegaLinter-Konfiguration (öffnet in einem neuen Tab) markiert den PMD-Schwellenwert mit dem Kommentar, dass nur der Release Manager ihn ändern darf, und // NOPMD ist „only for false positives, never to publish faster“ gedacht. Achten Sie auf die Option testCoverageNotBlocking, die laut Dokumentation (öffnet in einem neuen Tab) Deployments trotz zu geringer Abdeckung zulässt. Sie gehört in kein Produktions-Setup.

Gearset bringt mit Code Reviews (öffnet in einem neuen Tab) eigene, anpassbare Regelsätze für alle Metadatentypen mit, Flows eingeschlossen, dazu eine automatische Korrektur und Dashboards zu technischen Schulden. Als Status Check an einem geschützten Branch sperrt es laut Gearset (öffnet in einem neuen Tab) die Promotion eines Pull Requests, der die Prüfung nicht besteht. Eine eigene Regel meldet Flows ohne Test (öffnet in einem neuen Tab). Das spart Ihnen das Skript, das Sie sonst selbst schreiben.

Copado wirbt mit durchsetzbaren Quality Gates (öffnet in einem neuen Tab) entlang Ihrer Definition of Done und mit Robotic Testing für automatisierte Oberflächentests. Code Analyzer lässt sich laut Salesforce-Leitfaden (öffnet in einem neuen Tab) so einbinden, dass gewählte Schweregrade Deployments blockieren.

Flosum bietet einen Code-Scan-Schritt (öffnet in einem neuen Tab) in der Pipeline mit PMD oder einem eigenen, breiteren Regelsatz, der auch Flows prüft. Erreicht ein Fund die eingestellte Schwelle, scheitert der Schritt.

KI-generierter Code: dieselben Gates, keine Ausnahmen

Arbeiten Ihre Partner mit Coding-Agenten, steigt die Zahl der Pull Requests, Ihre Reviewkapazität bleibt gleich. Das spricht dafür, die Gates oben ohne Ausnahme durchzusetzen. Neue Gates braucht es kaum. Typische Fehler von KI-Code wie Abfragen in Schleifen, fehlende Sharing-Deklarationen und Tests ohne Aussage findet dieselbe Kombination aus Code Analyzer, Validierung und Review. Zwei Ergänzungen lohnen sich: eine Prüfung, die einen Sprung der API-Version auf 67.0 ohne Auftrag stoppt, und die Pflicht, KI-Anteile im Pull Request zu kennzeichnen.

Was KI-Code zusätzlich braucht, von der Regeldatei bis zu Org-Grenzen für Agenten, behandelt Kapitel 8 der KI-Masterclass. Die Gates im Detail stehen in Quality Gates für KI-Code, das Review aus Kundensicht in KI-generierten Salesforce-Code prüfen.

Durchgespielt: ein Flow mit Update in der Schleife

Ein Maschinenbauer betreibt Service Cloud mit Field Service für seine Außendiensttechniker, ein Händlerportal und eine Schnittstelle zu SAP. Zwei Partner arbeiten auf derselben Org, einer am Außendienst, einer am Portal. Alle Details sind Annahmen.

Ein Admin des ersten Partners baut einen record-triggered Flow auf dem Arbeitsauftrag, der bei Statuswechsel die zugehörigen Termine aktualisiert, mit einem Update-Element in einer Schleife. In der Sandbox funktioniert er mit einem Auftrag. Im Pull Request meldet der Flow Scanner DbInLoop und MissingFaultHandler, beide über der Schwelle, der Merge ist gesperrt. Der Admin baut das Update nach der Schleife, ergänzt einen Fehlerpfad und zwei Flow-Tests.

Im Validierungs-Deployment scheitert danach ein Apex-Test des zweiten Partners: Der Bulk-Test der SAP-Importklasse legt 200 Arbeitsaufträge an und läuft jetzt durch den neuen Flow. Ohne diesen Test wäre das Problem erst beim nächtlichen Import in Produktion aufgefallen. Das Review durch den Architekten des Kunden klärt am Ende die fachliche Frage, die kein Werkzeug stellt: ob der Termin bei einem stornierten Auftrag gelöscht oder nur abgesagt werden soll.

Welche Konfigurationsdaten solche Flows in Sandboxes brauchen, damit Tests aussagekräftig sind, behandelt Kapitel 7. Wie ich Programme dabei unterstütze, steht unter DevOps und Release-Management und Partnersteuerung.