Ich führe schon eine ganze Weile Interviews. Was in diesem schmerzhaften Prozess auffiel, war, dass das Interview zum Scheitern verurteilt war, wenn die Frage des Tests überhaupt aufgeworfen wurde. Das liegt daran, dass ich hauptsächlich Erfahrungen in der Frontend-Entwicklung gesammelt habe und die beiden Unternehmen, bei denen ich geblieben bin, beim Frontend-Testen sehr schlecht waren.

--- Überspringen, wenn Sie direkt zur Diskussion gehen möchten ---

Mein Mangel war in gewisser Weise ein Nebenprodukt der Industriekultur. Frontend-Tests gab es schon immer, aber vor einem Jahrzehnt trennte die Unternehmensstruktur Testbelange vom Entwicklungsprozess. Wir hatten also ein spezielles QA-Team, das E2E-/automatisierte Tests für uns Entwickler schrieb. Tests standen also nicht einmal in der Stellenbeschreibung. Die unglückliche Wahrheit kleiner Startups ist auch, dass die Bereitstellung immer über allem anderen steht. Da Tests die Produktivität beeinträchtigen, haben wir Entwickler keine Tests durchgeführt. Wir hatten nicht einmal eine Testbibliothek (Jasmine/Mocha/PhantomJS...) im Repo installiert.

Ich bekam meinen zweiten Job in einem viel größeren Unternehmen (das Consumer-Plattform-Team hatte etwa 150 Entwickler?). Es gab jedoch im Wesentlichen keine Tests. Jedes Team (Teams, aufgeteilt nach Funktionen wie Kasse, Treue, Registrierung usw.) hatte wiederum ein oder mehrere engagierte QA-Mitglieder, die diese E2E-Tests schreiben würden. Als sich diese Kultur etablierte und die Qualitätssicherung aus dem Budget gestrichen wurde, nahm sie niemand mehr auf, weil es niemanden gab, von dem man lernen konnte. Ich habe versucht, einige E2E-Tests für unser Team zu sammeln, aber der zurückgelassene Code war nicht einmal funktionsfähig und voller offensichtlicher Fehler (viele WTFs). In Kombination mit WIEDER knappen Fristen gerieten die Tests in Verzug. Das einzige Mal, dass über Tests gesprochen wurde, waren Dienstprogrammfunktionen und benutzerdefinierte Reaktions-Hooks.

--- Diskussion beginnt ---

Da ich von der No-Testing-Kultur geplagt bin, muss ich mir zumindest etwas einfallen lassen, das ich in Interviews zum abstrakten Testen sagen kann. Ich überspringe den üblichen Blödsinn, Stile oder Implementierungen nicht zu testen, was nicht.

Sie können die Diskussion gerne ergänzen. Das betrifft mindestens 300 meiner früheren Kollegen!

1.) globale Zustände testen:
Meiner Erfahrung nach ist die Verhaltensart „Wenn das passiert, erledigen wir das automatisch für Sie“ eine der krassesten Eigenschaften. Eine App, die ich hatte, war beispielsweise ein Diagrammvisualisierungs-Dashboard, das umfassend konfigurierbar war. Eine Konfigurationsänderung kann dazu führen, dass sich auch andere Konfigurationen ändern, je nachdem, welche Daten zurückgegeben werden und was nicht. Einige Konfigurationsnebeneffekte sind nicht einfach. Daher sollten Sie automatische Konfigurationsänderungen testen und prüfen, ob der Status auf der ganzen Linie bestehen bleibt/unverändert/konsistent ist. Wenn Sie also Tests zu dieser Art von Verhalten durchführen, die mit PM, Managern, Design und QA-Team abgestimmt sind, ist das äußerst wertvoll.

2.) Verbringen Sie nicht viel Zeit damit, die Integrität der UI-Eingabe zu testen:
Ich sehe einige Tutorials, in denen es um das Testen von Eingaben geht. Wenn ich beispielsweise „Taylor Swift“ in die Suchleiste eingebe und die Eingabetaste drücke, erhält unsere Suchfunktion „Taylor Swift“ als Eingabe.

Das ist einfach nicht hilfreich. Wenn Ihre Datenbindung unterbrochen ist, ist es entweder sehr offensichtlich, dass Sie sie während der Entwicklung selbst hätten erkennen sollen, oder sie ist nicht automatisch testbar, weil etwas die Funktionalität behindert hat, wie etwa ein unsichtbares Div über der Suchleiste, sodass Benutzer keine Suche eingeben können.

Wenn Sie jedoch nach Codezeilen bezahlt werden, fahren Sie fort :)

3.) Testeingaben als Nebeneffekt von Eingaben sind jedoch wünschenswert:
Im Gegensatz zu Nummer 2 sollten Sie Funktionsaufrufe testen, die völlige Nebeneffekte der Benutzerinteraktion sind. Wenn der Benutzer beispielsweise auf eine Schaltfläche klickt, sollte eine Anfrage aufgerufen werden, um diese Benutzeraktion für die Datenanalyse zu registrieren. Diese Art von Nebeneffekten, die völlig unabhängig von der Kernfunktionalität sind, sollten automatisch getestet werden, damit wir nicht von unbeabsichtigten Änderungen überrascht werden. Nebeneffekte, die nicht zum Kerngeschäft gehören, können für andere Teams von entscheidender Bedeutung sein, ich war in einem dieser anderen Teams :D

Wie gestalten Sie diese Testanforderungen?
Lassen Sie uns die Frontend-Architektur aufschlüsseln: MVC (Sie können sagen, Sie sind MVVM oder was nicht, das spielt keine Rolle).

V – Ansicht (html/jsx): Dies eignet sich hervorragend für E2E-/headerlose Browsertests und ist ein Industriestandard.

C – Controller (Geschäftslogik): Nehmen Sie sich etwas Zeit, um sicherzustellen, dass die Funktionen korrekt sind. Wenn Sie beispielsweise auf reine Funktionen abstrahieren, ist der erwartete Eingabe-Ausgabe-Prozess dann noch intakt? Etwas Industriestandard, aber die Leute machen sich normalerweise nicht die Mühe, zustandsbehaftete Funktionen in reine Funktionen umzuwandeln und zu testen.

M – Modell (API-Aufrufe/Zustände): Darauf möchte ich mich am meisten konzentrieren. Ihre (nicht rendernden) Zustände sollten pro Konzept global und Singleton sein. Keine neue Idee, da es sich im Grunde um Redux handelt. Für unsere Testzwecke muss es jedoch nicht Flux sein. Sie können Jotai-Atome haben, aber Sie können einen Wrapper codieren, damit Sie Ihre zentralisierten Setter-Funktionen zum Testen verfügbar machen können.

Das Ähnliche sollte bei Ihren API-Aufrufen/Drittanbieter-Bibliotheken durchgeführt werden. Es sollte global und Singleton sein, damit Sie sicher testen können, ob in der Anwendung ein Kern-/Nicht-Kern-API-Aufruf erfolgt, wenn ich das mache. Dies geschieht routinemäßig in Backend-Anwendungen, die meiner begrenzten Erfahrung nachgehen. Dies sollte auch in Frontend-Anwendungen erfolgen.

Wie klingt das? Ich bin mir sicher, dass das schon jemand gemacht hat, welche Erfahrungen habt ihr gemacht? Was kann verbessert werden? Ich würde gerne von Leuten hören, bei denen Frontend-Tests einfach über E2E/Headless-Browser und verrückte einfache Unit-Tests hinausgehen.