Wie strukturierst du eine UI-Automatisierungs-Codebase, damit sie nicht unwartbar wird?

Trenn die Schichten. Page- oder Component-Objects kapseln Selektoren und niedrigstufige Interaktionen; eine Flow-Schicht setzt sie zu fachlichen Aktionen wie Einloggen oder Checkout abschließen zusammen; Tests enthalten nur Absicht und Prüfungen. Halt Selektoren an einem Ort, bevorzuge dedizierte Test-Identifier gegenüber brüchigen CSS-Pfaden und halt Assertions aus Page-Objects heraus, damit Fehler auf die richtige Schicht zeigen.

Ich behandle Testcode wie Produktionscode, es gelten also dieselben Regeln: keine Duplikate, klare Schichten, sprechende Namen. Ganz unten habe ich Page- oder Component-Objects, die Selektoren und die Mechanik der Interaktion mit diesem UI-Teil besitzen. Darüber sitzt eine Flow-Schicht für fachliche Aktionen, also melde dich als Nutzer mit dieser Rolle an, oder leg einen Artikel rein und schließ den Checkout ab, denn solche Sequenzen werden ständig wiederverwendet und du willst sie nicht über vierzig Tests kopiert haben. Die Tests selbst lesen sich dann wie die Anforderung, überwiegend Methodenaufrufe und Prüfungen. Assertions halte ich aus Page-Objects heraus, denn wenn ein Page-Object prüft, sagt dir ein Fehlschlag, dass eine Seite unzufrieden ist, statt welches Verhalten gebrochen ist. Bei Selektoren dränge ich hart auf mit den Entwicklern abgestimmte Test-Attribute, denn CSS-Pfaden hinterherzujagen, die sich bei jedem Restyling ändern, ist der Hauptgrund, warum solche Suites aufgegeben werden. Und ich mache Setup über die API, wo immer es geht: geht es in einem Test um Checkout, sind Account und Warenkorb über HTTP anzulegen schneller und deutlich weniger brüchig, als sich durch zwölf Screens zu klicken.