So bauen Sie eine Salesforce-Testautomatisierungs-Pipeline in CI

Eine Salesforce-Testautomatisierungs-Pipeline führt deine Apex- und Lightning-Web-Component-Tests bei jedem Commit automatisch aus, bevor Code die Produktion erreicht. Ein funktionierendes Setup verbindet ein git-Repository mit einem CI-Runner, startet eine Scratch Org oder Sandbox, deployt die Metadaten, führt die Tests aus und lässt den Build fehlschlagen, wenn die Coverage unter die von Salesforce geforderten 75 Prozent fällt. Dieser Leitfaden geht die ganze Pipeline durch, von der ersten Testebene bis zu den Fallen, die Teams ausbremsen.

Was ist Salesforce-Testautomatisierung in CI?

Continuous Integration (CI) ist die Praxis, jede Änderung schon beim Eintreffen zu validieren, statt an einem Release-Tor. Für Salesforce heißt das eine Pipeline, die deine automatisierten Tests bei jedem Push oder Pull Request ausführt und den Merge blockiert, wenn etwas fehlschlägt. Das Ziel ist Shift-Left-Testing: einen kaputten Trigger oder eine fehlgeschlagene Assertion in Minuten auf einem Branch fangen, nicht bei einem Release-Nacht-Deployment in die Produktion.

Salesforce erzwingt eine harte Regel, die das unverzichtbar macht: Bevor du Apex in die Produktion deployen kannst, müssen deine Tests bestehen und du brauchst mindestens 75 Prozent Code Coverage. CI hält das durchgehend grün, statt beim Deployment zu improvisieren.

Was solltest du bei jedem Commit testen?

Eine brauchbare Salesforce-Suite ist geschichtet. Ziele darauf ab, das Schnellste zuerst abzudecken:

• Apex-Unit-Tests: das Rückgrat. Decke Trigger, Klassen und Geschäftslogik mit sinnvollen Assertions ab, nicht nur Coverage-Füllwerk.
• LWC-Jest-Tests: Komponentenlogik für Lightning Web Components, ausgeführt mit @salesforce/sfdx-lwc-jest. Diese sind schnell und laufen ohne Org.
• Integrations- und Smoke-Tests: eine dünne Schicht, die nach dem Deployment die kritischen End-to-End-Pfade und Drittanbieter-Integrationen prüft.

Führe Apex und Jest bei jedem Commit aus, weil sie schnell sind, und reserviere langsamere UI-End-to-End-Prüfungen für eine nächtliche Stufe. Unser Leitfaden dazu, was pro Pull Request läuft und was nachts, schlüsselt diese Aufteilung auf.

Wie richtet man eine CI-Pipeline für Salesforce-Tests ein?

Die beweglichen Teile sind gleich, ob du GitHub Actions, GitLab CI oder Jenkins nutzt. Eine minimale Pipeline tut bei jedem Pull Request Folgendes:

1. Authentifiziere die Salesforce CLI an einem Dev Hub, meist über einen JWT-Auth-Flow und ein hinterlegtes Zertifikat.
2. Erstelle eine Umgebung: starte eine Scratch Org (oder ziele auf eine dedizierte CI-Sandbox).
3. Deploye die Quelle mit sf project deploy start.
4. Führe Tests aus mit sf apex run test --test-level RunLocalTests --code-coverage --result-format human, und starte npm run test:unit für LWC Jest.
5. Verknüpfe den Build mit dem Ergebnis und lösche danach die Scratch Org, damit nichts hängen bleibt.

Salesforce veröffentlicht eine offizielle Anleitung zu Salesforce DX mit GitHub Actions, die sauber auf diese Schritte passt.

Welche Apex-Testebene sollte CI verwenden?

Die Testebene steuert, wie viel läuft und wie lange der Build dauert:

• RunLocalTests führt jeden Test in der Org aus außer denen aus installierten Managed Packages und ist die sichere Standardwahl für eine Validierungspipeline.
• RunSpecifiedTests führt nur benannte Klassen aus, nützlich für schnelles Branch-Feedback, aber riskant als Produktions-Tor, weil dabei Coverage fehlen kann.
• Eine neuere Ebene RunRelevantTests kam in der Spring-'26-Version als Beta, um Deployments zu verkürzen, indem nur die von einer Änderung betroffenen Tests laufen; behandle sie als Beta, bis du sie gegen deine Suite validiert hast.

Für den merge-blockierenden Build bevorzuge RunLocalTests, damit die Coverage echt ist. Nutze spezifizierte oder relevante Tests nur für schnelles, nicht-blockierendes Feedback früher im Branch.

Wo machen Teams bei Salesforce-CI Fehler?

Drei Fehler erklären die meisten festgefahrenen Pipelines:

Der Jagd nach der 75-Prozent-Zahl statt echter Assertions. Coverage ohne Assertions passiert das Tor und liefert trotzdem Bugs.

Die anderen beiden sind unzuverlässige Testdaten und eine Suite, die zu langsam wird, um bei jedem Commit zu laufen. Behebe das Erste, indem du Testdaten in jedem Test mit einem Factory-Muster und @testSetup erzeugst und dich nie auf Org-Daten verlässt. Behebe das Zweite, indem du schnelle Unit-Tests von langsamen End-to-End-Tests trennst, damit das Feedback dort, wo es am meisten zählt, unter wenigen Minuten bleibt. Werkzeuge der Salesforce-DevOps-Kategorie, darunter Copado, Gearset, Salto, AutoRABIT, Flosum und Blue Canvas, können diese Schritte in eine verwaltete Pipeline packen, falls du das YAML nicht von Hand bauen willst.

Für weitere Salesforce-DevOps-Anleitungen siehe unsere Ressourcen-Bibliothek.

FAQ

Welche Code Coverage verlangt Salesforce zum Deployen?

Mindestens 75 Prozent orgweite Apex-Coverage, und jeder Test muss bestehen. CI hält das durchgehend grün, statt ein Defizit erst beim Deployment zu entdecken.

Brauche ich Scratch Orgs für Salesforce-CI?

Nein, aber sie helfen. Scratch Orgs geben jedem Build eine saubere, wegwerfbare Umgebung. Eine dedizierte CI-Sandbox funktioniert auch, wenn Source Tracking und Reset sorgfältig verwaltet werden.

Wie teste ich Lightning Web Components in CI?

Nutze den Jest-basierten Runner @salesforce/sfdx-lwc-jest. Er führt Komponententests lokal ohne Org aus, schnell genug für jeden Commit.

Welches CI-Tool ist das beste für Salesforce?

GitHub Actions, GitLab CI und Jenkins funktionieren alle gut mit der Salesforce CLI. Der Runner zählt weniger als eine saubere Pipeline: authentifizieren, deployen, Tests ausführen, gaten, aufräumen.