Apex-Tests parallel ausführen ohne sporadische Fehlschläge

Damit Apex-Tests parallel ohne sporadische Fehlschläge laufen, muss jeder Test seine eigenen Daten anlegen, darf nie in Datensätze schreiben, die außerhalb des Tests existieren, und sollte eindeutige Werte für Felder wie Benutzernamen erzeugen. Verbleibende Flaky Tests diagnostizieren Sie, indem Sie die Klasse einzeln erneut ausführen: Läuft sie allein durch und scheitert nur parallel, haben Sie ein Isolationsproblem, keinen Bug. Paralleles Testen org-weit abzuschalten verdeckt das Symptom und verlangsamt jeden Lauf.

Warum scheitern Apex-Tests nur bei paralleler Ausführung?

Standardmäßig führt Salesforce asynchrone Testklassen gleichzeitig aus, sodass zwei Tests im selben Moment um dieselbe Ressource konkurrieren können. Die Fehler lassen sich auf drei Ursachen zurückführen:

• Konkurrenz um Datensatzsperren. Eine Transaktion, die auf einen gesperrten Datensatz wartet, hat 10 Sekunden, bevor Salesforce UNABLE_TO_LOCK_ROW zurückgibt, und dieses Limit ist nicht änderbar, wie Xappex erklärt. Übergeordnete Datensätze werden stillschweigend gesperrt, wenn Master-Detail-Kinder aktualisiert werden, Roll-up-Summaries neu berechnet werden und während der Freigabeverarbeitung.
• Salesforce-weit eindeutige Werte. Benutzernamen sind in ganz Salesforce eindeutig, daher scheitern zwei Klassen, die gleichzeitig [email protected] einfügen, mit DUPLICATE_USERNAME, ein Muster, das Salesforce Central beschreibt.
• Gemeinsam genutzte Org-Daten. Ein Test mit @isTest(SeeAllData=true) liest und schreibt echte Datensätze, die andere Tests zur selben Zeit berühren können.

Keines dieser Probleme tritt auf, wenn eine Klasse allein läuft, deshalb wirkt die Suite so zufällig.

Wie unterscheidet man einen Parallel-Flake von einem echten Bug?

1. Lesen Sie die Fehlermeldung. UNABLE_TO_LOCK_ROW, DUPLICATE_USERNAME und andere Duplicate-Value-Fehler auf Testdaten deuten auf Nebenläufigkeit hin.
2. Führen Sie die Klasse einzeln aus. Das Salesforce-CLI-Flag --synchronous führt die Testmethoden einer einzelnen Apex-Klasse synchron aus, laut der Dokumentation von plugin-apex.
3. Vergleichen Sie. Allein grün, parallel rot: Isolationsproblem. In beiden Fällen rot: ein echter Defekt. Beheben Sie ihn, statt ihn erneut laufen zu lassen.
4. Protokollieren Sie es. Notieren Sie Klasse, Fehler und Datum. Eine Klasse, die zweimal im Monat sporadisch scheitert, kommt ganz oben auf die Fix-Liste.

Wie macht man Apex-Tests sicher für die parallele Ausführung?

1. Alle Testdaten im Test selbst anlegen. Nutzen Sie @TestSetup oder eine Data Factory und verzichten Sie auf SeeAllData=true. Tests, die ihre eigenen Daten bauen, konkurrieren nicht um Org-Datensätze.
2. Nur in die eigenen Datensätze des Tests schreiben. Vermeiden Sie Updates an gemeinsam genutzten Setup-Datensätzen, am ausführenden Benutzer oder an allem, was eine Freigabe-Neuberechnung sperren könnte.
3. Eindeutige Felder pro Klasse eindeutig machen. Versehen Sie Benutzernamen und andere eindeutige Werte mit dem Namen der Testklasse plus einer Zufallszahl als Präfix.
4. Unit-Tests von Integrationstests trennen. Logik, die sich ohne DML testen lässt, nimmt nie eine Sperre. Halten Sie die schweren, datengebundenen Tests in einer kleineren Gruppe, die Sie genau beobachten.
5. Bewährte Klassen kennzeichnen. Winter '18 führte @isTest(isParallel=true) ein, um Klassen zu markieren, die ohne die standardmäßigen Nebenläufigkeitslimits parallel laufen können, wie FishOfPrey beschreibt. Setzen Sie es nur bei Klassen, die in parallelen Läufen wiederholt bestehen.

Sollte man einfach Disable Parallel Apex Testing aktivieren?

Nur als Notlösung. Die Einstellung finden Sie unter Setup, Apex Test Execution, Options. Sie führt asynchrone Tests nacheinander aus. Das beseitigt Nebenläufigkeits-Flakes, aber in Orgs mit vielen Testklassen kann ein vollständiger Lauf deutlich länger dauern. Manche Tools hängen am selben Schalter: Die Dokumentation von Gearset weist darauf hin, dass seine Test Monitors die Tooling API nutzen und Tests daher parallel ausführen, sofern Sie die Einstellung nicht aktivieren.

Betrachten Sie das Häkchen als Schuldenmarker. Aktivieren Sie es, um ein Release freizugeben, beheben Sie dann die verantwortlichen Klassen und deaktivieren Sie es wieder.

Wie führt man parallele Apex-Tests in der CI zuverlässig aus?

• Standardmäßig asynchron ausführen. sf apex run test --test-level RunLocalTests liefert denselben parallelen Lauf, den auch Ihre Produktions-Deployments sehen.
• Maschinenlesbare Ergebnisse erfassen. Ergänzen Sie --result-format junit --output-dir, damit Ihre Pipeline Fehler pro Klasse über die Zeit verfolgt, und --code-coverage, damit die Abdeckung sichtbar bleibt.
• Erst klassifizieren, dann einmal wiederholen. Wiederholen Sie synchron nur Fehler mit einer Nebenläufigkeitssignatur. Besteht die Wiederholung, protokollieren Sie einen Flake; scheitert sie, lassen Sie den Build scheitern.
• Die Flake-Rate beobachten. Eine steigende Zahl ist ein Problem im Testdesign, nicht in der Plattform.

Blinde Wiederholungen sind verlockend, machen aber aus echten Defekten grüne Builds. Dieselbe Disziplin gilt beim Toolwechsel, wie in Salesforce-DevOps-Tools wechseln, ohne die Pipeline zu brechen und in unserem Leitfaden zur Migration von Gearset zu Serpent ohne Ausfallzeit beschrieben.

Point-and-Click-Releases treffen auf dieselben Fehler, denn die Tests laufen beim Deployment trotzdem. Unsere Click-Deploy-Checkliste zeigt, was Sie zuerst prüfen sollten, und weitere Anleitungen finden Sie in den SF Guides.

Wer ist Tekunda?

Tekunda ist das Salesforce-Beratungs- und Produktunternehmen, das Serpent entwickelt, eine Salesforce-DevOps-Plattform mit GitHub-basierter Versionskontrolle und automatisierten Deployment-Pipelines. Wenn Flaky Tests Ihre Releases ausbremsen, vergleichen Sie die Pläne auf unserer Preisseite.

FAQ

Führt Salesforce Apex-Tests standardmäßig parallel aus?

Ja, asynchrone Testläufe führen Klassen gleichzeitig aus, außer Disable Parallel Apex Testing ist im Setup aktiviert.

Was verursacht UNABLE_TO_LOCK_ROW in Apex-Tests?

Zwei Transaktionen wollen denselben Datensatz, oft einen übergeordneten, der durch ein Master-Detail-Update, eine Roll-up-Summary oder eine Freigabe-Neuberechnung gesperrt ist. Die wartende Transaktion scheitert nach 10 Sekunden.

Sollte ich Flaky Apex-Tests automatisch wiederholen?

Einmal, synchron, und nur bei Nebenläufigkeitsfehlern. Protokollieren Sie jeden Flake und beheben Sie die Klasse, statt sich auf Wiederholungen zu verlassen.

Reicht isParallel=true, um Flaky Tests zu beheben?

Nein. Es kennzeichnet eine Klasse nur als parallelfähig. Der Test muss weiterhin seine eigenen Daten anlegen und eindeutige Werte verwenden.