Guter Beitrag von Thomas Ladd darüber, wie ihr Front-End-Team Tests durchführt. Die Liste fühlt sich wie ein guter Ausgangspunkt an.
- TypeScript – Eine Sprache, aber im Wesentlichen erhalten Sie verschiedene Tests kostenlos (Übergabe der richtigen Argumente und Variablentypen)
- Jest – Unit-Tests. JavaScript-Funktionen machen das Richtige. Funktioniert mit React.
- Cypress – Integrationstests. Seiten laden, Dinge mit der Seite tun, erwartete Dinge passieren im DOM. Thomas sagt, ihre End-to-End-Tests (z. B. Aufrufen von Diensten) werden ebenfalls in Cypress ohne jegliches Mocking von Daten durchgeführt.
Ich würde denken, dass dies ein Spiegelbild eines modernen Setups ist, das sich in vielen Frontend-Teams durchsetzt. Wenn es etwas hinzuzufügen gibt, würde ich visuelle Regressionstests (z. B. mit einem Tool wie Percy) als das hinzufügen.
Als Alternative zu Cypress ist auch jest-puppeteer erwähnenswert, da (1) Jest bereits verwendet wird und (2) Puppeteer vielleicht ein direkterer Weg ist, den Browser zu steuern – keine Mittelsmann-Sprache oder Electron oder irgendetwas.
Thomas schreibt sogar, dass es hier einen Nachteil gibt: zu viele Tools
Wir müssen nicht nur wissen, wie man in diesen verschiedenen Tools testet; wir müssen auch ständig entscheiden, welches Tool wir verwenden. Sollte ich einen E2E-Test schreiben, der diese Funktionalität abdeckt, oder reicht ein Integrationstest aus? Brauche ich auch Unit-Tests, die einige dieser feineren Details abdecken?
Zweifellos gibt es hier eine mentale Belastung, die nicht vorhanden ist, wenn man nur eine Wahl hat. Im Allgemeinen beginnen wir standardmäßig mit Integrationstests und fügen dann einen E2E-Test hinzu, wenn wir der Meinung sind, dass die Funktionalität besonders kritisch und backend-abhängig ist.
Ich bin mir nicht sicher, ob wir jemals an einem Punkt ankommen werden, an dem wir nur eine Art von Test schreiben müssen, aber es ist schön, wenn Unit- und Integrationstests eine gemeinsame Sprache teilen. Ich bin auch theoretisch gegenteilig in meiner Schlussfolgerung: Integrations-/E2E-Tests sind ein besserer Standard, da sie näher an der Realität sind und beweisen, dass sehr viel richtig läuft, indem sie nur eine Sache testen. Sie sollten der Standard sein. Allerdings sind sie auch langsamer und fehleranfälliger, also traurige Posaune.