Ein Locator ist ein Vertrag, keine Koordinate

page.locator('.panel > div:nth-child(3) > button.primary') funktioniert heute. Es funktioniert morgen. Es funktioniert so lange, bis ein Designer den Knopf um einen Platz nach links verschiebt, und dann scheitert Ihre Suite an einer Funktion, die niemand kaputt gemacht hat. Sie haben keinen Test geschrieben. Sie haben ein Foto des DOM geschrieben.

Was Playwright tatsächlich empfiehlt

Die Playwright-Dokumentation geht diesbezüglich ungewöhnlich direkt aus. Der Locator-Leitfaden empfiehlt die Priorisierung benutzerbezogener Attribute und expliziter Verträge: getByRole, getByLabel, getByText, getByPlaceholder, getByTestId. Rollenlokatoren spiegeln wider, wie Benutzer und unterstützende Technologien die Seite wahrnehmen. Test-IDs erstellen einen separaten expliziten Vertrag, allerdings sind sie für Benutzer unsichtbar. Sie bleiben nur dann stabil, wenn die Entwickler diesen Vertrag einhalten. CSS- und XPath-Selektoren gelten als fragil, da sie an die DOM-Struktur gebunden sind und sich die DOM-Struktur ändert.

Zwei Eigenschaften des Frameworks belohnen die gute Angewohnheit. Locators werden vor jeder Aktion neu aufgelöst, sodass ein erneutes Rendern zwischen zwei Schritten nicht dazu führt, dass Sie ein veraltetes Element behalten. Und Locators sind streng: Wenn Ihr Selektor mit zwei Elementen übereinstimmt, wird die Aktion ausgelöst, anstatt stillschweigend auf das erste zu klicken. Ein strikter CI-Versagen ist einen Nachmittag lang ärgerlich. Ein falscher Klick im falschen Dialog führt zu einem Fehlerbericht mit Ihrem Namen.

Warum Generatoren zuerst zur schlechten Angewohnheit greifen

Eine generierte Suite kann nach einem Selektor greifen, der auf der aktuellen Seite aufgelöst wird, ohne zu berücksichtigen, was sich durch eine Neugestaltung ändert. Dabei handelt es sich um ein Überprüfungsrisiko und nicht um einen Beweis für die Trainingsdaten eines bestimmten Modells. An das Layout gebundene Tests können am ersten Tag bestanden werden und nach einer Front-End-Änderung aus Gründen, die nichts mit dem Produktverhalten zu tun haben, fehlschlagen.

Der Misserfolg ist in gewisser Weise kostspielig: Die Suite schreit bei jeder Neugestaltung laut, das Team lernt, rote Builds zu ignorieren, und der einzige echte Rückschritt segelt durch eine Wand aus vertrautem Lärm.

Ein 15-minütiges Audit für jede Suite

Grep Ihre Tests für page.locator mit CSS- oder XPath-Strings und für getByText, das für interaktive Elemente verwendet wird. Stellen Sie für jeden Treffer eine Frage: Benennt dieser Selektor, um welches Element es sich handelt oder wo es sich befindet? Koordinaten durch Verträge ersetzen:

• Schaltflächen und Links: getByRole mit dem zugänglichen Namen.
• Formularfelder: getByLabel oder getByPlaceholder als Fallback.
• Wiederholter oder dynamischer Inhalt: ein mit den Entwicklern vereinbarter data-testid.
• getByText: nützlich für Textinhalte; Bevorzugen Sie eine Rolle und einen zugänglichen Namen, wenn Sie auf ein Steuerelement klicken.

Sie werden mit einer Handvoll wirklich mehrdeutiger Steuerelemente zurückbleiben. Das ist kein Testproblem. Sie stellen ein Barrierefreiheitsproblem dar, das die Tests gerade kostenlos festgestellt haben.

Die Strenge-Falle, und wenn first() ein Geständnis ist

Playwright-Locators sind streng: Eine Aktion auf einem Selektor, der mit zwei Elementen übereinstimmt, löst einen Verstoß aus, anstatt zu raten. Behandeln Sie jeden Fehler im strikten Modus als Designfrage. Wenn Sie .first() benötigen, damit die Suite erfolgreich ist, trifft eines von zwei Dingen zu: Die Seite rendert doppelte Steuerelemente, die eindeutige, zugängliche Namen haben sollten, oder Ihr Selektor ist zu breit. Beides sind Feststellungen, keine Unannehmlichkeiten. Die Lösung besteht darin, mit einem benannten Vertrag einzugrenzen, nach einem stabilen übergeordneten Element zu filtern oder nach einer Test-ID zu fragen. Wenn Suiten diese Woche nach .nth(1) greifen, weil das zweite Spiel zufällig das richtige ist, lernen sie nach der nächsten Veröffentlichung, auf das falsche Dialogfeld zu klicken.

Es gibt eine legitime Notluke. locator.or() gibt es für die Fälle, in denen die Seite ehrlich einen von zwei Status anzeigt, z. B. ein Anmeldeformular oder ein Banner für bereits angemeldete Benutzer. Verwenden Sie es bewusst, benennen Sie beide Alternativen und lesen Sie es wie einen Zweig. Verwenden Sie es, um Unklarheiten zu überdecken, und es liest sich wie ein Schulterzucken.

Wo Agenten passen

Lassen Sie den Agenten erkunden und entwerfen; In den Locators befindet sich Ihre Bewertung. Ein mit getByRole('button', { name: 'Save' }) generierter Test sagt Ihnen, was die Seite seiner Meinung nach tut. Ein generierter Test mit div:nth-child(3) sagt Ihnen nichts, außer dass das DOM einmal so aussah. Behalten Sie die erste Sorte. Schreiben Sie die Sekunde neu, bevor sie CI erreicht, denn jedes spröde Ortungsgerät, das Sie akzeptieren, ist ein zukünftiger Fehlalarm, für den Sie bereits bezahlt haben.