Ein separater Browser ist kein separates Konto
Browserkontexte trennen Cookies, aber keine gemeinsamen Serverdaten. Parallele Tests mit Schreibzugriff brauchen getrennte Konten und Daten.
Übersetzte Ausgabe. Technische Kennungen bleiben in ihrer ursprünglichen Form.
Zwei Beispieltests laufen gleichzeitig. Der erste erwartet die Zeitzone UTC. Der zweite speichert "Europe/Riga". Beide haben einen neuen Browserkontext, nutzen aber dasselbe Konto. Der erste schlägt fehl, weil der Serverdatensatz verändert wurde, obwohl die Cookies getrennt sind.
Diese Unterscheidung ist wichtig, wenn ein Agent mehr Abdeckung generiert als Ihre alte Suite. Durch die parallele Ausführung können Annahmen zum gemeinsamen Zustand offengelegt werden, die verborgen blieben, als Tests nacheinander ausgeführt wurden. Das praktische Artefakt ist eine Eigentumskarte: Welcher Test darf welches Konto und welchen Datensatz schreiben und wann wird dieser Status zurückgesetzt?
Zeichnen Sie die beiden Grenzen getrennt
Im Authentifizierungsleitfaden von Playwright wird die Isolierung des Browserkontexts und das Laden des authentifizierten Status erläutert. Außerdem wird gewarnt, dass Tests, die den serverseitigen Status ändern, unterschiedliche Konten verwenden sollten, wenn die gleichzeitige Verwendung einen anderen Test beeinträchtigen würde. Ein Kontext ist eine Clientgrenze. Ein Konto-, Mandanten- oder Datensatz-Namespace ist eine Anwendungsgrenze. Keiner ist ein Ersatz für den anderen.
Listen Sie beide im Test auf. Ein generierter Test sollte den Kontext identifizieren, den er verwendet, und die Daten, die er ändern kann. Wenn nur unveränderliche Inhalte gelesen werden, kann die gemeinsame Nutzung eines Kontos sinnvoll sein. Wenn Einstellungen geändert, Bestellungen erstellt oder ein freigegebenes Dokument bearbeitet werden, überprüfen Sie die Konto- und Datensatzeigentümerschaft, bevor Sie die Zahl der Parallelarbeiter erhöhen.
Wählen Sie die kleinste nützliche Eigentumseinheit
Der Playwright-Leitfaden dokumentiert ein Konto pro Parallelarbeiter für Tests, die den serverseitigen Status ändern. Dadurch können Störungen zwischen den Arbeitnehmern verringert werden. Dies bedeutet nicht, dass jeder Test innerhalb eines Workers willkürliche Änderungen hinterlassen kann. Setzen Sie den Status, den jeder Test benötigt, zurück oder setzen Sie ihn als Seed, und machen Sie die Bereinigung explizit.
Manchmal ist die sicherere Einheit ein eindeutiger Datensatz pro Test und nicht ein Konto pro Test. Bei einer teameigenen Aufgabenliste können verschiedene Konten dennoch dieselbe gemeinsame Liste schreiben. Für einen Checkout-Ablauf ist möglicherweise ein eindeutiger Warenkorb- oder Bestellnamensraum erforderlich. Wählen Sie die Einheit anhand der tatsächlichen Freigaberegeln des Produkts aus, nicht anhand des Namens der Browser-API.
Ein Datenvertrag, dem ein Agent folgen kann
Schreiben Sie neben jedes Szenario vier Felder: Eigentümer-Namespace, Setup-Status, zulässige Schreibvorgänge und Bereinigungsverhalten. Ein beispielhafter Vertrag könnte einen Staging-Benutzer für einen Arbeiter reservieren, vor dem Test einen leeren Wagen setzen, die Erstellung nur synthetischer Bestellungen zulassen und diese Bestellungen unter Beibehaltung der Fehlernachweise löschen. Geben Sie an, was passiert, wenn die Bereinigung fehlschlägt. andernfalls erbt der nächste Lauf ein Rätsel.
Behalten Sie die Einrichtung unabhängig vom Erfolg eines anderen Tests bei. Playwright-Geräte bieten einen strukturierten Lebenszyklus für die Vorbereitung und Freigabe von Testressourcen. Nutzen Sie diesen Lebenszyklus, um den Besitz lesbar zu machen und nicht, um ein globales gemeinsames Konto hinter einem praktischen Gerätenamen zu verbergen. Der Prüfer sollte in der Lage sein, herauszufinden, wem jede veränderbare Ressource gehört.
Ein QA-Team kann diese Karte verwenden, um weniger Zeit damit zu verbringen, versehentliche Cross-Test-Fehler zu verfolgen. Ein Team ohne Qualitätssicherung kann mit einem kritischen Flow und einem begrenzten Staging-Kontopool beginnen. Keiner von beiden muss eine riesige Umgebung aufbauen, bevor er prüft, ob der erste Fluss nützlich ist.
Der Authentifizierungsstatus ist eine geheimnisvolle Datei
Playwright warnt davor, dass der gespeicherte Browserstatus Cookies und Header enthalten kann, die die Identität eines Kontos vortäuschen können. Der Leitfaden rät davon ab, diese Dateien in Repositories, einschließlich privater, zu übertragen. Behandeln Sie sie als Anmeldeinformationen: Halten Sie sie von Quellarchiven fern, beschränken Sie den Zugriff und generieren Sie sie bei Bedarf neu.
Geben Sie einem Explorationsagenten niemals eine Produktionssitzung, nur weil die Anmeldeeinrichtung unbequem ist. Verwenden Sie Staging-Konten mit den für das Szenario erforderlichen Berechtigungen. Ein separater Browser, der ein Administrator-Cookie trägt, ist immer noch ein Administrator.
Zählen Sie falsche Fehler als echte Arbeit
Verfolgen Sie Fehler, die durch den gemeinsamen Status verursacht werden, getrennt von Produktregressionen. Berücksichtigen Sie die Minuten, die für das erneute Seeding von Konten und die Untersuchung von Eingriffen in die Reparaturkosten eines Automatisierungspiloten aufgewendet wurden. Mehr generierte Tests können die Abdeckung erhöhen, aber auch zu Konflikten führen, wenn die Eigentumsverhältnisse unklar sind. Die Einsparung erfolgt, wenn nützliche Abdeckung und vorhersehbare Daten die Wiederholungsarbeit reduzieren, und nicht, wenn allein die Testanzahl steigt.
Häufige Fragen
Isoliert ein neuer Browserkontext Serverdaten?
Nein. Es trennt den clientseitigen Browserstatus, aber zwei authentifizierte Kontexte können immer noch dasselbe Konto oder denselben Serverdatensatz ändern.
Sollte jeder Test ein anderes Konto verwenden?
Nicht unbedingt. Dramatiker dokumentiert gemeinsame Konten für Tests, die nicht stören, und ein Konto pro Parallelarbeiter für Autoren im Serverstatus. Freigegebene Produktdatensätze müssen möglicherweise weiter getrennt werden.
Kann ich den authentifizierten Speicherstatus festschreiben?
Playwright warnt davor, dass es Cookies und Header enthalten könnte, die die Identität eines Kontos vortäuschen können, und rät davon ab, es auch nur an private Repositories zu übertragen.