Wie entscheidest du, was du in einer Frontend-Codebase testest, und womit?

Teste Verhalten auf der Ebene, auf der ein Nutzer es erlebt. Komponententests, die eine Komponente rendern und über sichtbaren Text und Rollen mit ihr interagieren, fangen die meisten Bugs pro Aufwand; reine Unit-Tests passen zu Logik wie Formatierung und Reducern; ein kleiner Satz End-to-End-Tests deckt die kritischen Wege wie Signup und Checkout ab. Meide Tests, die auf Implementierungsdetails prüfen, weil sie bei jedem Refactor brechen, ohne echte Regressionen zu fangen.

Meine Regel ist, dass ein Test scheitern soll, wenn das Verhalten bricht, und ein Refactor ihn überleben soll. Die meisten meiner Tests rendern also eine Komponente und bedienen sie so, wie ein Nutzer es täte, und finden Elemente über Rolle und Label statt über Test-Ids oder Klassennamen, wodurch nebenbei die Barrierefreiheit der Komponente mit geübt wird. Reine Logik wie ein Datumsformatierer oder ein Reducer bekommt schlichte Unit-Tests, weil die billig und schnell sind. Dazu eine kleine End-to-End-Suite in Playwright über die Wege, die Geld kosten, wenn sie brechen: Registrieren, Einloggen, Checkout. Netzwerkaufrufe fange ich an der Grenze mit einem Mock-Server ab, statt die fetch-Funktion zu mocken, damit der Test meinen echten Request-Code abdeckt. Was ich vermeide, sind große Snapshot-Tests, weil niemand einen Diff über zweihundert Zeilen prüft und sie blind abgenickt werden, und alles, was auf internen Zustand prüft. Worauf ich außerdem bestehe: End-to-End-Tests laufen gegen eine geseedete Umgebung, denn flackernde geteilte Daten sind der Grund, warum Teams anfangen, rote Builds zu ignorieren.