Frontend-Test: Was und wie zu testen, und welches Tool zu verwenden?

Question

Ich habe schon eine Weile Tests für meinen Ruby-Code geschrieben, aber als Frontend-Entwickler bin ich natürlich daran interessiert, diesen Code in den Code zu schreiben, den ich für meinen Frontend-Code schreibe. Es gibt durchaus ein paar verschiedene Möglichkeiten, die ich mit dem Spielen um wurden:

• CasperJS
• Capybara & Rspec
• Jasmine
• Gurke oder nur Rspec

Was sind die Menschen für den Test? Und was testen die Menschen noch? Nur JavaScript? Links? Formen? Hardcoded Inhalt?

Alle Gedanken würden sehr geschätzt werden.

Answer 1

Dafür gibt es viele Optionen und Tools. Aber ihre Wahl hängt davon ab, ob Sie eine Web-Benutzeroberfläche oder eine Desktop-App haben.

Angenommen, von den Tools, die Sie erwähnt haben, ist es Web-UI. Ich würde vorschlagen Selenium (alias WebDriver): http://seleniumhq.org/docs/

Es gibt eine Vielzahl von Sprachen, die es unterstützt (Ruby ist in der Liste). Es kann gegen eine Vielzahl von Browsern betrieben werden, und es ist ziemlich einfach zu verwenden mit vielen Tutorials und Tipps zur Verfügung. Oh, und es ist frei, natürlich :)

Answer 2

Ich hatte die gleichen Fragen vor ein paar Monaten und, nachdem ich mit vielen Entwicklern gesprochen und viel Forschung getan habe, ist das, was ich herausgefunden habe. Sie sollten Unit-Test Ihr JavaScript, schreiben Sie eine kleine Reihe von UI-Integrationstests und vermeiden Sie Record und Playback-Test-Tools. Lassen Sie mich das genauer erklären.

Betrachten Sie zuerst die test pyramid. Dies ist eine interessante Analogie von Mike Cohn erstellt, die Ihnen helfen wird zu entscheiden, welche Art von Tests Sie tun sollten. Am unteren Ende der Pyramide befinden sich die Komponententests, die solide sind und schnelle Rückmeldungen liefern. Diese sollten die Grundlage Ihrer Teststrategie bilden und somit den größten Teil der Pyramide einnehmen. Oben haben Sie die UI-Tests. Das sind die Tests, die direkt mit Ihrer Benutzeroberfläche interagieren, wie Selenium zum Beispiel. Obwohl diese Tests Ihnen helfen können, Fehler zu finden, sind sie teurer und liefern sehr langsames Feedback. Je nachdem, welches Werkzeug Sie verwenden, werden sie auch sehr brüchig und Sie werden mehr Zeit für die Pflege dieser Tests aufwenden, als den tatsächlichen Produktionscode zu schreiben. Die Service-Schicht in der Mitte enthält Integrationstests, für die keine Benutzeroberfläche erforderlich ist. In Rails zum Beispiel würden Sie Ihre REST-Schnittstelle direkt testen, anstatt mit den DOM-Elementen zu interagieren.

Nun zurück zu Ihrer Frage. Ich fand heraus, dass ich die Anzahl der Bugs in meinem Projekt erheblich reduzieren konnte, das ist eine Web-Anwendung, die in Spring Roo (Java) mit Tonnen von JavaScript geschrieben wurde, einfach indem ich genug Komponententests für JS schrieb. In meiner Anwendung ist viel Logik in JS geschrieben und das ist die Art von Dingen, die ich hier teste. Ich bin nicht besorgt darüber, wie die Seite tatsächlich aussehen wird oder ob die Animationen so abgespielt werden, wie sie sollten. Ich teste, ob die Module, die ich in JS schreibe, die erwartete Logik ausführen, ob Elementklassen korrekt zugewiesen sind und ob Fehlerbedingungen gut gehandhabt werden. Für diese Tests verwende ich Jasmine. Dies ist ein großartiges Werkzeug. Es ist sehr einfach zu lernen und hat nette Spottfähigkeiten, die Spione genannt werden. Jasmine-jQuery fügt mehr großartige Funktionalität hinzu, wenn Sie jQuery verwenden. Insbesondere können Sie Fixtures angeben, bei denen es sich um Snippets des HTML-Codes handelt, sodass Sie das DOM nicht manuell vortäuschen müssen. Ich habe dieses Tool in Maven integriert und diese Tests sind Teil meiner CI-Strategie.

Sie müssen vorsichtig mit UI-Tests sein, besonders wenn Sie sich auf Aufnahme/Wiedergabe-Tools wie Selenium verlassen. Da sich die Benutzeroberfläche häufig ändert, werden diese Tests immer wieder unterbrochen und Sie werden viel Zeit darauf verwenden, herauszufinden, ob die Tests wirklich fehlgeschlagen sind oder ob sie gerade veraltet sind. Außerdem fügen sie nicht so viel Wert hinzu wie Unit Tests. Da sie eine integrierte Umgebung benötigen, um sie auszuführen, werden Sie diese meist erst nach Abschluss der Entwicklung verwenden, wenn die Kosten für die Fehlerbehebung höher sind.

Für Rauch/Regressionstests sind UI-Tests jedoch sehr nützlich. Wenn Sie diese automatisieren müssen, sollten Sie auf einige Gefahren achten. Schreiben Sie Ihre Tests, notieren Sie sie nicht. Aufgezeichnete Tests basieren normalerweise auf automatisch generierten XPaths, die für jede kleine Änderung, die Sie an Ihrem Code vornehmen, unterbrochen werden. Ich glaube, Gurke ist ein guter Rahmen für das Schreiben dieser Tests und Sie können es zusammen mit WebDriver verwenden, um die Browser-Interaktion zu automatisieren. Code, der über Tests denkt. In UI-Tests müssen Sie Elemente leichter finden, damit Sie nicht auf komplexe XPaths angewiesen sind. Hinzufügen von Klassen- und ID-Elementen, wo Sie normalerweise nicht sind, wird häufig vorkommen. Schreiben Sie keine Tests für jede kleine Ecke. Diese Tests sind teuer zu schreiben und zu lange dauern. Sie sollten sich auf die Fälle konzentrieren, die die meisten Ihrer Funktionen untersuchen. Wenn Sie auf dieser Ebene zu viele Tests schreiben, werden Sie vermutlich die gleiche Funktionalität testen, die Sie zuvor bei Ihren Komponententests getestet haben (vorausgesetzt, Sie haben sie geschrieben).

In meinem aktuellen Projekt verwende ich Spock und Geb, um die UI-Tests zu schreiben. Ich finde diese Werkzeuge erstaunlich. Sie sind in Groovy geschrieben, was besser zu meinem Java-Projekt passt.

Answer 3

Ich obwohl dieser Beitrag viele Likes bekommt, würde ich meine Antwort auf meine Frage posten, da ich jetzt viele Tests schreibe und wie Sie das Frontend testen, ist jetzt viel weitergegangen.

So in Bezug auf den FE-Tests verbrachte ich viel Zeit karma mit Jasmine verwenden, obwohl Karma gut mit anderen Test-Suiten wie Mokka & QUnit arbeiten. Während diese sind großartig und Karma ermöglicht es Ihnen, direkt mit Browsern zu verbinden, um Ihre Tests auszuführen. Der Nachteil ist, wenn Ihre Testsuite groß wird, kann es ziemlich langsam werden.

So kürzlich habe ich umgezogen zu Jest, die viel schneller ist und wenn Sie schreiben App zu schreiben, verwenden Sie enzyme mit Snap-Shot-Tests geben Sie wirklich gute Abdeckung. Apropos Coverage Jest hat die Abdeckung in Istanbul eingebaut und eingerichtet und verspottet ist wirklich einfach, einfach zu bedienen. Der Nachteil ist, dass es nicht im Browser getestet wird und es etwas benutzt, das jsdom genannt wird, das schnell ist, aber einige Ärgernisse hat. Persönlich finde ich das nicht besonders schlimm, wenn ich meinen Code über webpack/babel kompiliere, was bedeutet, dass die Cross-Browser-Bugs relativ gering sind, also generell kein Problem ist, wenn Sie trotzdem manuell testen (und imo sollten Sie).

In Bezug auf die Arbeit innerhalb der Schienen-Stack, so einfach jetzt, dass der Webpacker Edelstein ist jetzt verfügbar und mit npm und Knoten ist in der Regel viel mehr ausgenommen. Ich würde empfehlen, nvm zu verwenden, um Ihre Knotenversionen

zu verwalten Während das nicht streng prüft, würde ich auch empfehlen, das Linting zu verwenden, da dieses auch viele Probleme in Ihrem Code aufhebt. Für JS I eslint mit prettier und SCSS/css verwenden Ich verwende stylelint

In Bezug auf das, was zu testen, ich denke, als Carlos über den Test Pyramide spricht immer noch relevant ist, nach der alle Theorie, ändert sich nicht nur die Werkzeuge . Ich würde auch hinzufügen, um Tests praktisch zu sein, würde ich immer testen, aber auf welche Ebene und Abdeckung wird das Projekt abhängen. Es ist wichtig, Ihre Zeit und die Stunden/Tage zu verwalten, um ein kurzes Lebenszyklusprojekt zu testen.Größere/längerfristige Projekte Die Vorteile einer größeren Testsuite sind offensichtlich größer.

Wie auch immer ich hoffe, dass hilft Menschen, die auf die Frage schauen.