Salesforce-Testautomatisierung in CI: Was pro Pull Request läuft und was nachts

Kurze Antwort: Auf jedem Pull Request laufen nur die schnellen, deterministischen Prüfungen: statische Analyse des Diffs, LWC-Jest und ein reines Validierungs-Deployment des Deltas, das ausschließlich die Apex-Tests für den geänderten Code ausführt. Alles Langsame oder Instabile, vollständige Testläufe, UI-Strecken und externe Integrationen, gehört in einen nächtlichen Job. Ziel ist ein Ergebnis in unter zehn Minuten, denn danach liest es niemand mehr.

Was gehört auf jeden Pull Request?

• Statische Analyse des Diffs. Sekunden, ohne Org, fängt die mechanischen Probleme, bevor ein Mensch den Code liest.
• LWC-Jest-Tests. Sie laufen außerhalb der Plattform in Node und brauchen überhaupt keine Org.
• Ein reines Validierungs-Deployment des Deltas gegen eine zielähnliche Org, mit einem Test-Level, das nur die abdeckenden Klassen ausführt.
• Metadatenprüfungen. Keine unbeabsichtigten Löschungen, keine still verschwindenden Profil- oder Permission-Set-Einträge.

Eine Regel bestimmt diese Liste: Alles am Pull-Request-Gate muss deterministisch sein. Ein einziger instabiler Test bringt dem Team bei, auf Wiederholen zu drücken, und ein Gate, das man bis Grün wiederholt, ist Dekoration.

Was gehört in den nächtlichen Job?

• Ein vollständiger lokaler Apex-Lauf gegen die Integrations-Sandbox. Er fängt die Klasse, von der Sie nicht wussten, dass Ihre Änderung sie berührt.
• UI-Strecken über die zentralen Geschäftsprozesse.
• Integrationstests gegen externe Systeme, deren Latenz und Verfügbarkeit Sie nicht steuern.
• Eine Drift-Prüfung zwischen Integrations-Org und Branch, damit direkte Änderungen im Setup am nächsten Morgen sichtbar sind.
• Der Coverage-Trend auf Org-Ebene, als Bericht und nicht als Gate.

Nächtliche Fehler werden beim Kaffee sortiert. Genau das ist der Zweck: Sie stehen nicht zwischen einer Entwicklerin und ihrem Merge.

Was läuft nur vor einem Release?

• Die vollständige Regressionssuite und ein Abnahmedurchlauf.
• Performance- und Massendatentests, die Volumen brauchen, das eine Scratch Org nicht hat.
• Ein Validierungs-Deployment gegen die Produktion, gefolgt von einem Quick Deploy, damit das Release-Fenster nicht mit Warten auf Tests vergeht.

Wie passen die Salesforce-Test-Level dazu?

Vier Level, und die Wahl je Stufe ist der größte Teil des Entwurfs (Metadata-API-Guide).

• NoTestRun: in einer Scratch Org in Ordnung, nie auf einem Weg in die Produktion.
• RunSpecifiedTests: Ihr Pull-Request-Gate. Eine Falle sollte man kennen: Auf diesem Level muss jede Klasse und jeder Trigger im Paket einzeln 75% Abdeckung erreichen, je Komponente berechnet und nicht org-weit (Salesforce-Dokumentation).
• RunLocalTests: alles außer Tests aus Managed Packages. Das führt ein Produktions-Deployment mit Apex standardmäßig aus.
• RunAllTestsInOrg: zusätzlich die Tests der Managed Packages. Selten gewünscht und langsam.

Die Plattformregeln darunter bleiben gleich: Mindestens 75% Ihres Apex-Codes müssen abgedeckt sein, um in die Produktion zu deployen, jeder Trigger braucht mindestens eine abgedeckte Zeile, und jeder ausgeführte Test muss bestehen, unabhängig vom Prozentwert (Salesforce Help).

Wie hält man die Pull-Request-Schleife unter zehn Minuten?

1. Deployen Sie das Delta, nicht die Org. Validieren Sie nur, was der Branch geändert hat.
2. Leiten Sie die Testliste ab. Erzeugen Sie die angegebenen Testklassen aus den geänderten Komponenten statt aus einer handgepflegten Liste.
3. Parallelisieren Sie. Jest und statische Analyse laufen neben der Org-Validierung, nicht dahinter in der Warteschlange.
4. Halten Sie eine warme Ziel-Org bereit. Eine Org je Pull Request anzulegen und zu befüllen ist meist der größte Zeitblock. Nutzen Sie einen Pool oder eine langlebige Validierungs-Sandbox.
5. Cachen Sie Abhängigkeiten zwischen Läufen, inklusive CLI und Node-Modulen.
6. Stubben oder verschieben Sie externe Aufrufe. Was Sie in der Antwortzeit nicht kontrollieren, gehört in den nächtlichen Job.
7. Messen Sie die Laufzeit und zeigen Sie sie sichtbar an. Pipeline-Dauer wächst leise, und immer nur in eine Richtung.

Wohin gehören UI-Tests?

Nicht auf den Pull Request. UI-Tests sind das Langsamste und Sprödeste in einer Salesforce-Pipeline: Shadow DOM in Lightning-Komponenten, generierte Element-Ids und Login-Dialoge zerlegen Selektoren aus Gründen, die mit der geprüften Änderung nichts zu tun haben.

Praktikabel ist ein kleiner Smoke-Satz aus fünf bis zehn kritischen Strecken nach dem Merge in den Integrations-Branch und die vollständige Suite nachts. Faustregel: Fällt ein UI-Test zweimal aus anderen Gründen als dem Produkt aus, ist er eine Wartungsaufgabe und kein Gate.

Wie setzt man Coverage-Gates?

• Prüfen Sie den Pull Request auf die Abdeckung des geänderten Codes, nicht auf die org-weite Zahl. Die bewegt sich träge und versteckt brandneue ungetestete Klassen hinter jahrealten.
• Behalten Sie die org-weite Untergrenze als Release-Gate, wo sie hingehört.
• Machen Sie den Prozentsatz nicht zum Ziel. Salesforce empfiehlt selbst, jeden Anwendungsfall abzudecken, positiv und negativ, Massen- und Einzelsatz, und die Zahl folgen zu lassen.

Dieser Leitfaden ist Teil unserer Salesforce-DevOps-Guides.

FAQ

Wie schnell sollte eine Salesforce-Pull-Request-Prüfung sein?

Unter zehn Minuten von Anfang bis Ende. Danach wechseln Entwickler den Kontext, lesen die Ausgabe nicht mehr, und die Prüfung ändert kein Verhalten mehr.

Sollen alle Apex-Tests auf jedem Pull Request laufen?

Nein. Führen Sie die Tests für die geänderten Klassen mit RunSpecifiedTests aus und heben Sie den vollständigen lokalen Lauf für die Nacht und die Release-Validierung auf.

Welche Abdeckung verlangt Salesforce wirklich?

75% Apex org-weit für ein Produktions-Deployment, mindestens eine abgedeckte Zeile pro Trigger, und jeder ausgeführte Test muss bestehen. Bei RunSpecifiedTests braucht jede Klasse und jeder Trigger im Paket 75% für sich.

Brauchen LWC-Jest-Tests eine Salesforce-Org?

Nein. Sie laufen außerhalb der Plattform in Node, und genau deshalb gehören sie ans Pull-Request-Gate statt in den nächtlichen Job.

Wo sollten UI-Tests laufen?

Ein kleiner Smoke-Satz nach dem Merge, die vollständige Suite nachts. Sie auf den Pull Request zu setzen ist der schnellste Weg, einem Team beizubringen, einen roten Build zu ignorieren.