• Haupt / Wie Man

Eine Einführung in das Frontend-Testen

Seite 1 von 2: Verschiedene Arten von Frontend-Tests (und wann sie verwendet werden sollen)

• Verschiedene Arten von Frontend-Tests (und wann sie verwendet werden sollen)
• Umfassen und Durchsetzen einer Testkultur

Das Testen von Frontend-Code ist für viele Entwickler immer noch eine verwirrende Praxis. Da die Frontend-Entwicklung jedoch immer komplexer wird und Entwickler wie nie zuvor für Stabilität und Konsistenz verantwortlich sind, müssen Frontend-Tests als gleichberechtigter Bürger in Ihrer Codebasis anerkannt werden. Wir teilen Ihre verschiedenen Testoptionen auf und erklären, für welche Situationen sie am besten geeignet sind.

Frontend-Tests sind ein Sammelbegriff, der eine Vielzahl automatisierter Teststrategien abdeckt. Einige davon, wie Unit- und Integrationstests, sind seit Jahren eine anerkannte Best Practice in der Backend-Entwicklergemeinschaft. Andere Strategien sind neuer und ergeben sich aus den Änderungen in der Backend- und Frontend-Entwicklung, die derzeit verwendet werden.

Am Ende dieses Artikels sollten Sie sich sicher fühlen, welche Teststrategien am besten zu Ihrem Team und Ihren Codebasen passen. Die folgenden Codebeispiele werden mit dem Jasmine-Framework geschrieben, aber die Regeln und Prozesse sind in den meisten Test-Frameworks ähnlich.

• Beste Teile der Benutzertestsoftware

01. Unit Testing

Unit Testing, einer der Testveteranen, befindet sich auf dem niedrigsten Niveau aller Testtypen. Damit soll sichergestellt werden, dass die kleinsten Bits Ihres Codes (Einheiten genannt) wie erwartet unabhängig voneinander funktionieren.

Stellen Sie sich vor, Sie haben ein Lego-Set für ein Haus. Bevor Sie mit dem Bauen beginnen, sollten Sie sicherstellen, dass jedes einzelne Stück berücksichtigt wird (fünf rote Quadrate, drei gelbe Rechtecke). Durch Unit-Tests wird sichergestellt, dass einzelne Codesätze - z. B. Eingabevalidierungen und Berechnungen - wie vorgesehen funktionieren, bevor das größere Feature erstellt wird.

Es ist hilfreich, über Unit-Tests in Verbindung mit dem Mantra „Mach eins gut“ nachzudenken. Wenn Sie einen Code mit einer einzigen Verantwortung haben, möchten Sie wahrscheinlich einen Komponententest dafür schreiben.

Schauen wir uns das folgende Code-Snippet an, in dem wir einen Komponententest für einen einfachen Taschenrechner schreiben:

describe('Calculator Operations', function () { it('Should add two numbers', function () { Calculator.init(); var result = Calculator.addNumbers(7,3); expect(result).toBe(10); }); });

In unserer Taschenrechner Anwendung wollen wir sicherstellen, dass die Berechnungen immer unabhängig funktionieren, wie wir es erwarten. Im Beispiel möchten wir sicherstellen, dass wir immer zwei Zahlen genau addieren können.

Als erstes beschreiben wir die Testreihe, die wir mit Jasmines durchführen werden beschreibt . Dadurch wird eine Testsuite erstellt - eine Gruppierung von Tests, die sich auf einen bestimmten Bereich der Anwendung beziehen. Für unseren Rechner gruppieren wir jeden Berechnungstest in einer eigenen Suite.

Suiten eignen sich nicht nur hervorragend für die Code-Organisation, sondern auch, weil Sie damit Suiten selbst ausführen können. Wenn Sie an einer neuen Funktion für eine Anwendung arbeiten, möchten Sie nicht jeden Test während der aktiven Entwicklung ausführen, da dies sehr zeitaufwändig wäre. Durch das individuelle Testen von Suiten können Sie sich schneller entwickeln.

Als nächstes schreiben wir unsere tatsächlichen Tests. Verwendung der es Funktion schreiben wir die Funktion, die wir testen. In unserem Beispiel wird die Additionsfunktion getestet, sodass Szenarien ausgeführt werden, die bestätigen, dass sie ordnungsgemäß funktioniert.

Wir schreiben dann unsere Testzusicherung, in der wir testen, ob unser Code wie erwartet funktioniert. Wir initialisieren unseren Rechner und führen unseren aus addNumbers Funktion mit den beiden Zahlen, die wir hinzufügen möchten. Wir speichern die Zahl als Ergebnis und behaupten dann, dass dies der erwarteten Zahl entspricht (in unserem Fall 10).

Wenn addNumbers Wenn die korrekten Zahlen nicht zurückgegeben werden, schlägt unser Test fehl. Wir würden ähnliche Tests für unsere anderen Berechnungen schreiben - Subtraktion, Multiplikation und so weiter.

02. Abnahmetests

Wenn Unit-Tests wie die Überprüfung jedes Lego-Teils sind, prüfen Abnahmetests, ob jede Bauphase abgeschlossen werden kann. Nur weil alle Teile berücksichtigt werden, bedeutet dies nicht, dass die Anweisungen ordnungsgemäß ausführbar sind und Sie das endgültige Modell erstellen können.

Abnahmetests durchlaufen Ihre laufende Anwendung und stellen sicher, dass bestimmte Aktionen, Benutzereingaben und Benutzerflüsse abgeschlossen werden und funktionieren.

Nur weil unsere Bewerbung addNumbers Die Funktion gibt die richtige Zahl zurück. Dies bedeutet nicht, dass die Taschenrechnerschnittstelle definitiv wie erwartet funktioniert, um das richtige Ergebnis zu erzielen. Was passiert, wenn unsere Schaltflächen deaktiviert sind oder das Berechnungsergebnis nicht angezeigt wird? Abnahmetests helfen uns bei der Beantwortung dieser Fragen.

describe('Sign Up Failure state', function () { it('Shouldn't allow signup with invalid information', function () { var page = visit('/home'); page.fill_in('input[name='email']', 'Not An Email'); page.click('button[type=submit]'); page.click('button[type=submit]'); expect(page.find('#signupError').hasClass('hidden')).toBeFalsy(); }); });

Die Struktur sieht unserem Unit-Test sehr ähnlich: Wir definieren eine Suite mit beschreibt , dann schreibe unseren Test in die es Funktion, dann führen Sie einen Code aus und überprüfen Sie das Ergebnis.

Anstatt bestimmte Funktionen und Werte zu testen, testen wir hier, ob sich ein bestimmter Workflow (ein Anmeldefluss) wie erwartet verhält, wenn wir schlechte Informationen eingeben. Hier finden mehr winzige Aktionen statt, z. B. Formularvalidierungen, die möglicherweise einer Einheitentest unterzogen werden, sowie die Behandlung des Fehlerzustands, der durch ein Element mit der ID demonstriert wird signupError .

Abnahmetests sind eine hervorragende Möglichkeit, um sicherzustellen, dass wichtige Erfahrungsabläufe immer korrekt funktionieren. Es ist auch einfach, Tests für Randfälle hinzuzufügen und Ihren QS-Teams dabei zu helfen, sie in Ihrer Anwendung zu finden.

Wenn Sie überlegen, wofür Sie Abnahmetests schreiben sollen, sind Ihre User Stories ein guter Ausgangspunkt. Wie interagiert Ihr Benutzer mit Ihrer Website und was ist das erwartete Ergebnis dieser Interaktion? Es unterscheidet sich von Unit-Tests, die besser auf Funktionsanforderungen abgestimmt sind, z. B. auf die Anforderungen rund um ein validiertes Feld.

03. Visuelle Regressionstests

Wie in der Einleitung erwähnt, sind einige Testarten in der Frontend-Welt einzigartig. Die erste davon ist die visuelle Regression. Dadurch wird Ihr Code nicht getestet, sondern das gerenderte Ergebnis Ihres Codes - Ihrer Benutzeroberfläche - mit der gerenderten Version Ihrer Anwendung in der Produktion, im Staging oder in einer vorab geänderten lokalen Umgebung verglichen.

Dies erfolgt normalerweise durch Vergleichen von Screenshots, die in einem Headless-Browser (einem Browser, der auf dem Server ausgeführt wird) aufgenommen wurden. Bildvergleichstools erkennen dann Unterschiede zwischen den beiden Aufnahmen.

Mit einem Tool wie PhantomCSS legen Ihre Tests fest, wohin der Testläufer navigieren soll, machen einen Screenshot und das Framework zeigt Ihnen Unterschiede, die in diesen Ansichten aufgetreten sind.

casper.start('/home').then(function(){ // Initial state of form phantomcss.screenshot('#signUpForm', 'sign up form'); // Hit the sign up button (should trigger error) casper.click('button#signUp'); // Take a screenshot of the UI component phantomcss.screenshot('#signUpForm', 'sign up form error'); // Fill in form by name attributes & submit casper.fill('#signUpForm', { name: 'Alicia Sedlock', email: '[email protected]' }, true); // Take a second screenshot of success state phantomcss.screenshot('#signUpForm', 'sign up form success'); });

Im Gegensatz zu Akzeptanz- und Unit-Tests ist es schwierig, visuelle Regressionstests zu nutzen, wenn Sie etwas Neues erstellen. Da sich auf Ihrer Benutzeroberfläche im Verlauf der aktiven Entwicklung schnelle und drastische Änderungen ergeben, werden Sie diese Tests wahrscheinlich speichern, wenn Teile der Benutzeroberfläche visuell vollständig sind. Daher sind visuelle Regressionstests die letzten Tests, die Sie schreiben sollten.

Derzeit erfordern viele visuelle Regressionstools ein wenig manuellen Aufwand. Möglicherweise müssen Sie Ihre Screenshot-Erfassung ausführen, bevor Sie mit der Entwicklung in Ihrem Zweig beginnen, oder die Basis-Screenshots manuell aktualisieren, wenn Sie Änderungen an der Benutzeroberfläche vornehmen.

Dies liegt einfach an der Natur der Entwicklung - Änderungen an der ZWIEBEL mag beabsichtigt sein, aber Tests wissen nur 'Ja, das ist das Gleiche' oder 'Nein, das ist anders'. Wenn visuelle Regressionen jedoch ein Problem in Ihrer Anwendung darstellen, kann dieser Ansatz Ihrem Team insgesamt Zeit und Mühe sparen, verglichen mit der ständigen Korrektur von Regressionen.

04. Zugänglichkeits- und Leistungstests

Mit der Kultur und dem Bewusstsein für Frontend-Tests wächst auch unsere Fähigkeit, verschiedene Aspekte des Ökosystems zu testen. Angesichts des verstärkten Fokus auf Barrierefreiheit Durch die Integration in unsere Testsuite in unsere technische Kultur wird sichergestellt, dass diese Konzepte weiterhin Priorität haben.

Wenn Sie Probleme bei der Durchsetzung von Leistungsbudgets oder Barrierefreiheitsstandards haben, können Sie diese Anforderungen auf diese Weise im Blick behalten.

Beide Überprüfungen können entweder mit Build-Tools wie Grunt und Gulp oder halbmanuell in Ihrem Terminal in Ihren Workflow integriert werden. Für Leistungsbudgets bietet Ihnen ein Tool wie grunt-perfbudget die Möglichkeit, Ihre Site innerhalb einer bestimmten Aufgabe automatisch über WebPageTest auszuführen.

Wenn Sie jedoch keinen Task-Runner verwenden, können Sie perfbudget auch als eigenständiges NPM-Modul verwenden und die Tests manuell ausführen.

So sieht es aus, wenn Sie dies über das Terminal ausführen:

perfbudget --url http://www.aliciability.com --key [WebPageTest API Key] --SpeedIndex 2000 --render 400 And likewise, setting up through Grunt: perfbudget: { default: { options: { url: 'http://aliciability.com', key: 'WebPageTest API Key', budget: { SpeedIndex: '2000', render: '400' } } } } [...] grunt.registerTask('default', ['jshint', 'perfbudget']);

Die gleichen Optionen stehen für Zugänglichkeitstests zur Verfügung. Für Pa11y können Sie also entweder das ausführen pa11y Befehl in Ihrem Browser zur Ausgabe oder Einrichtung einer Aufgabe zur Automatisierung dieses Schritts. Im Terminal:

pa11y aliciability.com // As a JavaScript command after NPM install var pa11y = require('pa11y'); // require pa11y var test = pa11y(); // get pa11y ready to set test.run('aliciability.com', function (error, results) { // Log our parse your results });

Die meisten Tools in diesen Kategorien sind ziemlich Plug-and-Play-fähig, bieten Ihnen jedoch auch die Möglichkeit, die Ausführung der Tests anzupassen. Sie können sie beispielsweise so einstellen, dass bestimmte WCAG-Standards ignoriert werden.

Nächste Seite: So führen Sie Tests in Ihren Workflow ein

• 1
• zwei

Aktuelle Seite: Verschiedene Arten von Frontend-Tests (und wann sie verwendet werden sollen)

Nächste Seite Umfassen und Durchsetzen einer Testkultur