Front-End Testing is For Everyone

Testing ist eines dieser Dinge, bei denen man entweder super begeistert ist oder die Augen schließt und davonläuft. In welchem Lager Sie sich auch immer befinden, ich sage Ihnen, dass Front-End-Tests für jeden etwas sind. Tatsächlich gibt es viele Arten von Tests, und vielleicht rühren daher einige der anfänglichen Ängste oder Verwirrung.

In diesem Artikel werde ich die beliebtesten und am weitesten verbreiteten Testarten behandeln. Für einige von Ihnen ist das vielleicht nichts Neues, aber es kann zumindest als Auffrischung dienen. So oder so, mein Ziel ist es, dass Sie eine gute Vorstellung von den verschiedenen Testarten bekommen, die es gibt. Unit. Integration. Barrierefreiheit. Visuelle Regressionstests. Darauf werden wir uns gemeinsam konzentrieren.

Und nicht nur das! Wir werden auch auf die Bibliotheken und Frameworks hinweisen, die für jede Testart verwendet werden, wie Mocha. Jest, Puppeteer und Cypress, unter anderem. Und keine Sorge – ich werde viel technisches Kauderwelsch vermeiden. Das gesagt, sollten Sie *etwas* Erfahrung mit der Front-End-Entwicklung haben, um die Beispiele zu verstehen, die wir behandeln werden.

OK, legen wir los!

Was ist Testen?

Softwaretests sind eine Untersuchung, die durchgeführt wird, um Stakeholdern Informationen über die Qualität des zu testenden Softwareprodukts oder der Dienstleistung zu liefern.

Cem Kaner, „Exploratory Testing“ (17. November 2006)

Im Grunde ist Testen ein automatisiertes Werkzeug, das Fehler in Ihrer Entwicklung so früh wie möglich findet. So können Sie diese Probleme beheben, bevor sie in die Produktion gelangen. Tests dienen auch als Erinnerung daran, dass Sie möglicherweise vergessen haben, Ihre eigene Arbeit in einem bestimmten Bereich zu überprüfen, z. B. die Barrierefreiheit.

Kurz gesagt, Front-End-Tests validieren, dass das, was die Leute auf der Website sehen, und die Funktionen, die sie darauf nutzen, wie vorgesehen funktionieren.

Front-End-Tests sind für die Client-Seite Ihrer Anwendung. Zum Beispiel können Front-End-Tests validieren, dass das Drücken einer „Löschen“-Schaltfläche ein Element ordnungsgemäß vom Bildschirm entfernt. Sie prüfen jedoch nicht unbedingt, ob das Element tatsächlich aus der Datenbank entfernt wurde – das würde während der Back-End-Tests abgedeckt.

Das ist Testen in aller Kürze: Wir wollen Fehler auf der Client-Seite abfangen und beheben, bevor Code bereitgestellt wird.

Unterschiedliche Tests befassen sich mit unterschiedlichen Teilen des Projekts

Verschiedene Testarten decken unterschiedliche Aspekte eines Projekts ab. Dennoch ist es wichtig, sie zu unterscheiden und die Rolle jeder Art zu verstehen. Wenn man verwirrt ist, welche Tests was tun, erhält man einen unordentlichen, unzuverlässigen Testsuit.

Idealerweise würden Sie mehrere verschiedene Testarten verwenden, um verschiedene Arten möglicher Probleme aufzudecken. Einige Testarten verfügen über eine Testabdeckungsanalyse, die zeigt, wie viel Ihres Codes (als Prozentsatz) von diesem speziellen Test betrachtet wird. Das ist ein großartiges Feature, und obwohl ich Entwickler gesehen habe, die 100 % Abdeckung anstreben, würde ich mich allein auf diese Metrik nicht verlassen. Das Wichtigste ist sicherzustellen, dass alle möglichen Randfälle abgedeckt und berücksichtigt werden.

Wenden wir uns also den verschiedenen Testarten zu. Denken Sie daran, dass Sie nicht unbedingt jeden einzelnen davon verwenden müssen. Es geht darum, die Tests unterscheiden zu können, damit Sie wissen, welche Sie unter bestimmten Umständen einsetzen müssen.

Unit-Tests

• Level: Niedrig
• Umfang: Testet die Funktionen und Methoden einer Anwendung.
• Mögliche Werkzeuge:, AVA, Jasmine, Jest, Karma, Mocha

Unit-Tests sind der grundlegendste Baustein für das Testen. Sie betrachten einzelne Komponenten und stellen sicher, dass sie wie erwartet funktionieren. Diese Art von Tests ist entscheidend für jede Front-End-Anwendung, da damit Ihre Komponenten auf ihr erwartetes Verhalten getestet werden, was zu einer wesentlich zuverlässigeren Codebasis und App führt. Hier können auch Randfälle berücksichtigt und abgedeckt werden.

Unit-Tests sind besonders gut zum Testen von APIs geeignet. Aber anstatt Aufrufe an eine Live-API zu tätigen, stellen hartkodierte (oder „gemockte“) Daten sicher, dass Ihre Testläufe stets konsistent sind.

Nehmen wir eine sehr einfache (und primitive) Funktion als Beispiel

const sayHello = (name) => {
  if (!name) {
    return "Hello human!";
  }

  return `Hello ${name}!`;
};

Auch dies ist ein einfacher Fall, aber Sie können sehen, dass er einen kleinen Randfall abdeckt, bei dem jemand vergessen haben könnte, der Anwendung einen Vornamen zu geben. Wenn es einen name gibt, erhalten wir „Hallo ${name}!“ wobei ${name} das ist, was wir vom Benutzer erwarten würden.

„Ähm, warum müssen wir so etwas Kleines testen?“, fragen Sie sich vielleicht. Dafür gibt es einige sehr wichtige Gründe.

• Es zwingt Sie, tief über die möglichen Ergebnisse Ihrer Funktion nachzudenken. Mehr als oft genug entdecken Sie tatsächlich Randfälle, was Ihnen hilft, diese in Ihrem Code abzudecken.
• Ein Teil Ihres Codes kann von diesem Randfall abhängen, und wenn jemand etwas Wichtiges löscht, wird der Test ihn warnen, dass dieser Code wichtig ist und nicht entfernt werden darf.

Unit-Tests sind oft klein und einfach. Hier ist ein Beispiel

describe("sayHello function", () => {
  it("should return the proper greeting when a user doesn't pass a name", () => {
    expect(sayHello()).toEqual("Hello human!")
  })

  it("should return the proper greeting with the name passed", () => {
    expect(sayHello("Evgeny")).toEqual("Hello Evgeny!")
  })
})

describe und it sind nur syntaktischer Zucker. Die wichtigsten Zeilen sind expect und toEqual. describe und it teilen den Test in logische Blöcke auf, die im Terminal ausgegeben werden. Die Funktion expect nimmt die Eingabe entgegen, die wir validieren möchten, während toEqual die gewünschte Ausgabe annimmt. Es gibt viele verschiedene Funktionen und Methoden, die Sie zum Testen Ihrer Anwendung verwenden können.

Nehmen wir an, wir arbeiten mit Jest, einer Bibliothek zum Schreiben von Units. Im obigen Beispiel zeigt Jest die Funktion sayHello als Titel im Terminal an. Alles innerhalb einer it-Funktion wird als einzelner Test betrachtet und unter dem Funktionsnamen im Terminal gemeldet, was alles sehr leicht lesbar macht.

Integrationstests

• Level: Mittel
• Umfang: Testet Interaktionen zwischen Einheiten.
• Mögliche Werkzeuge: AVA, Jest, Testing Library

Wenn Unit-Tests das Verhalten eines Blocks überprüfen, stellen Integrationstests sicher, dass die Blöcke einwandfrei zusammenarbeiten. Das macht Integrationstests sehr wichtig, da sie das Testen von Interaktionen zwischen Komponenten ermöglichen. Es ist sehr selten (wenn überhaupt), dass eine Anwendung aus isolierten Teilen besteht, die für sich allein funktionieren. Deshalb verlassen wir uns auf Integrationstests.

Wir greifen auf die Funktion zurück, die wir mit Unit-Tests getestet haben, verwenden sie aber diesmal in einer einfachen React-Anwendung. Nehmen wir an, das Klicken auf eine Schaltfläche löst eine Begrüßung auf dem Bildschirm aus. Das bedeutet, dass ein Test nicht nur die Funktion, sondern auch das HTML-DOM und die Funktionalität einer Schaltfläche umfasst. Wir wollen testen, wie all diese Teile zusammenspielen.

Hier ist der Code für eine <Greeting />-Komponente, die wir testen

export const Greeting = () => {  
  const [showGreeting, setShowGreeting] = useState(false);  

 return (  
   <div>  
     <p data-testid="greeting">{showGreeting && sayHello()}</p>  
     <button data-testid="show-greeting-button" onClick={() => setShowGreeting(true)}>Show Greeting</button>  
   </div>
 );  
};

Hier ist der Integrationstest

describe('<Greeting />', () => {  
  it('shows correct greeting', () => {  
    const screen = render(<Greeting />);  
     const greeting = screen.getByTestId('greeting');  
     const button = screen.getByTestId('show-greeting-button');  

     expect(greeting.textContent).toBe('');  
     fireEvent.click(button);  
     expect(greeting.textContent).toBe('Hello human!');  
 });  
});

Wir kennen describe und it bereits von unserem Unit-Test. Sie gliedern Tests in logische Teile. Wir haben die Funktion render, die eine <Greeting />-Komponente in einem speziellen emulierten DOM anzeigt, damit wir Interaktionen mit der Komponente testen können, ohne das echte DOM zu berühren – andernfalls kann das kostspielig sein.

Als Nächstes fragt der Test die Elemente <p> und <button> über Test-IDs ab (#greeting bzw. #show-greeting-button). Wir verwenden Test-IDs, da es einfacher ist, die gewünschten Komponenten aus dem emulierten DOM zu erhalten. Es gibt andere Möglichkeiten, Komponenten abzufragen, aber so mache ich es am häufigsten.

Erst in Zeile 7 beginnt der eigentliche Integrationstest! Zuerst prüfen wir, ob das <p>-Tag leer ist. Dann klicken wir auf die Schaltfläche, indem wir ein click-Ereignis simulieren. Und schließlich prüfen wir, ob das <p>-Tag „Hallo Mensch!“ enthält. Das ist alles! Wir testen nur, dass ein leerer Absatz nach dem Klicken auf eine Schaltfläche Text enthält. Unsere Komponente ist abgedeckt.

Wir können natürlich eine Eingabe hinzufügen, bei der jemand seinen Namen eingibt und wir diese Eingabe in der Begrüßungsfunktion verwenden. Ich habe mich jedoch entschieden, es etwas einfacher zu halten. Wir werden Eingaben verwenden, wenn wir andere Testarten behandeln.

Sehen Sie, was wir im Terminal erhalten, wenn wir den Integrationstest ausführen

End-to-End (E2E)-Tests

• Level: Hoch
• Umfang: Testet Benutzerinteraktionen in einem echten Browser, indem Anweisungen für das Vorgehen und erwartete Ergebnisse bereitgestellt werden.
• Mögliche Werkzeuge: Cypress, Puppeteer

E2E-Tests sind die höchste Testebene auf dieser Liste. E2E-Tests kümmern sich nur darum, wie Benutzer Ihre Anwendung sehen und mit ihr interagieren. Sie wissen nichts über den Code und die Implementierung.

E2E-Tests weisen dem Browser an, was er tun soll, worauf geklickt und was eingegeben werden soll. Wir können alle Arten von Interaktionen erstellen, die verschiedene Funktionen und Abläufe testen, wie sie der Endbenutzer erlebt. Es ist buchstäblich ein Roboter, der eine Anwendung durchklickt, um sicherzustellen, dass alles funktioniert.

E2E-Tests ähneln in gewisser Weise Integrationstests. E2E-Tests werden jedoch in einem echten Browser mit einem echten DOM ausgeführt, anstatt in etwas, das wir uns ausdenken – wir arbeiten im Allgemeinen mit echten Daten und einer echten API in diesen Tests.

Es ist gut, vollständige Abdeckung mit Unit- und Integrationstests zu haben. Benutzer können jedoch unerwartete Verhaltensweisen erleben, wenn sie eine Anwendung im Browser ausführen – E2E-Tests sind die perfekte Lösung dafür.

Sehen wir uns ein Beispiel mit Cypress an, einer äußerst beliebten Testbibliothek. Wir werden sie speziell für einen E2E-Test unserer früheren Komponente verwenden, diesmal in einem Browser mit einigen zusätzlichen Funktionen.

Auch hier müssen wir den Code der Anwendung nicht sehen. Wir gehen einfach davon aus, dass wir eine Anwendung haben und sie als Benutzer testen wollen. Wir wissen, welche Schaltflächen zu klicken sind und welche IDs diese Schaltflächen haben. Das ist alles, was wir wirklich als Grundlage haben.

describe('Greetings functionality', () => {  
  it('should navigate to greetings page and confirm it works', () => {
    cy.visit('https://:3000')  
    cy.get('#greeting-nav-button').click()  
    cy.get('#greetings-input').type('Evgeny', { delay: 400 })  
    cy.get('#greetings-show-button').click()  
    cy.get('#greeting-text').should('include.text', 'Hello Evgeny!')  
  })  
})

Dieser E2E-Test sieht unserem vorherigen Integrationstest sehr ähnlich. Die Befehle sind äußerst ähnlich, der Hauptunterschied besteht darin, dass diese in einem echten Browser ausgeführt werden.

Zuerst verwenden wir cy.visit, um zu einer bestimmten URL zu navigieren, auf der sich unsere Anwendung befindet

cy.visit('https://:3000')

Zweitens verwenden wir cy.get, um die Navigationsschaltfläche anhand ihrer ID abzurufen, und weisen dann den Test an, darauf zu klicken. Diese Aktion navigiert zu der Seite mit der <Greetings />-Komponente. Tatsächlich habe ich die Komponente auf meiner persönlichen Website hinzugefügt und ihr eine eigene URL-Route zugewiesen.

cy.get('#greeting-nav-button').click()

Dann rufen wir nacheinander die Texteingabe ab, geben „Evgeny“ ein, klicken auf die Schaltfläche #greetings-show-button und prüfen schließlich, ob wir die gewünschte Begrüßung erhalten haben.

cy.get('#greetings-input').type('Evgeny', { delay: 400 })
cy.get('#greetings-show-button').click()
cy.get('#greeting-text').should('include.text', 'Hello Evgeny!')  

Es ist ziemlich cool zu sehen, wie der Test die Schaltflächen für Sie in einem echten Live-Browser klickt. Ich habe den Test ein wenig verlangsamt, damit Sie sehen können, was vor sich geht. All das passiert normalerweise sehr schnell.

Hier ist die Terminalausgabe

Barrierefreiheitstests

• Level: Hoch
• Umfang: Testet die Benutzeroberfläche Ihrer Anwendung anhand von Kriterien für Barrierefreiheitsstandards.
• Mögliche Werkzeuge: AccessLint, axe-core, Lighthouse, pa11y

Web-Barrierefreiheit bedeutet, dass Websites, Tools und Technologien so konzipiert und entwickelt werden, dass Menschen mit Behinderungen sie nutzen können.

W3C

Barrierefreiheitstests stellen sicher, dass Menschen mit Behinderungen eine Website effektiv nutzen können. Diese Tests validieren, dass Sie die Standards für den Aufbau einer Website mit Blick auf Barrierefreiheit einhalten.

Zum Beispiel verwenden viele blinde Menschen Bildschirmlesegeräte. Bildschirmlesegeräte scannen Ihre Website und versuchen, sie Benutzern mit Behinderungen in einem Format (normalerweise gesprochen) zu präsentieren, das diese Benutzer verstehen können. Als Entwickler möchten Sie die Arbeit eines Bildschirmlesegeräts erleichtern, und Barrierefreiheitstests helfen Ihnen zu verstehen, wo Sie anfangen sollen.

Es gibt viele verschiedene Werkzeuge, einige davon automatisiert und einige, die manuell ausgeführt werden, um die Zugänglichkeit zu validieren. Chrome hat zum Beispiel bereits ein Werkzeug direkt in seinen DevTools integriert. Sie kennen es vielleicht als Lighthouse.

Verwenden wir Lighthouse, um die Anwendung zu validieren, die wir im Abschnitt E2E-Tests erstellt haben. Wir öffnen Lighthouse in den Chrome DevTools, wählen die Testoption „Barrierefreiheit“ und generieren den Bericht.

Das ist buchstäblich alles, was wir tun müssen! Lighthouse erledigt seine Aufgabe, erstellt dann einen ansprechenden Bericht mit einer Bewertung, einer Zusammenfassung der durchgeführten Audits und einer Übersicht über Möglichkeiten zur Verbesserung der Bewertung.

Aber dies ist nur ein Werkzeug, das die Barrierefreiheit aus seiner spezifischen Perspektive misst. Wir haben alle Arten von Werkzeugen zur Barrierefreiheit, und es lohnt sich, einen Plan zu haben, was getestet werden soll und welche Werkzeuge verfügbar sind, um diese Punkte zu erreichen.

Visuelle Regressionstests

• Level: Hoch
• Umfang: Testet die visuelle Struktur der Anwendung, einschließlich der visuellen Unterschiede, die durch eine Codeänderung entstehen.
• Mögliche Werkzeuge: Cypress, Percy, Applitools

Manchmal reichen E2E-Tests nicht aus, um zu überprüfen, ob die letzten Änderungen an Ihrer Anwendung das visuelle Erscheinungsbild von etwas in einer Benutzeroberfläche nicht beeinträchtigt haben. Haben Sie Code mit einigen Änderungen in die Produktion hochgeladen, nur um festzustellen, dass er das Layout eines anderen Teils der Anwendung beschädigt hat? Nun, Sie sind nicht allein. Meistens als nicht, dass Änderungen am Codebase die visuelle Struktur oder das Layout einer App beschädigen.

Die Lösung sind visuelle Regressionstests. Die Funktionsweise ist ziemlich unkompliziert. Visuelle Tests nehmen einfach einen Screenshot von Seiten oder Komponenten auf und vergleichen ihn mit Screenshots, die in früheren erfolgreichen Tests aufgenommen wurden. Wenn diese Tests Diskrepanzen zwischen den Screenshots feststellen, erhalten wir eine Benachrichtigung.

Wenden wir uns einem visuellen Regressionstool namens Percy zu, um zu sehen, wie visuelle Regressionstests funktionieren. Es gibt viele andere Möglichkeiten, visuelle Regressionstests durchzuführen, aber ich denke, Percy ist einfach in Aktion zu zeigen. Tatsächlich können Sie Paul Ryans ausführliche Beschreibung von Percy hier auf CSS-Tricks lesen. Aber wir werden etwas deutlich Einfacheres tun, um das Konzept zu veranschaulichen.

Ich habe absichtlich das Layout unserer Greeting-Anwendung beschädigt, indem ich die Schaltfläche nach unten zum Eingabefeld verschoben habe. Versuchen wir, diesen Fehler mit Percy zu erfassen.

Percy funktioniert gut mit Cypress, sodass wir deren Installationsanleitung befolgen und Percy-Regressionstests zusammen mit unseren bestehenden E2E-Tests ausführen können.

describe('Greetings functionality', () => {  
  it('should navigate to greetings page and confirm everything is there', () => {  
    cy.visit('https://:3000')  
    cy.get('#greeting-nav-button').click()  
    cy.get('#greetings-input').type('Evgeny', { delay: 400 })  
    cy.get('#greetings-show-button').click()  
    cy.get('#greeting-text').should('include.text', 'Hello Evgeny!')  


    // Percy test
     cy.percySnapshot() // HIGHLIGHT
  })  
})

Alles, was wir am Ende unseres E2E-Tests hinzugefügt haben, ist eine Einzeiler: cy.percySnapshot(). Dies nimmt einen Screenshot auf und sendet ihn an Percy zum Vergleichen. Das ist alles! Nachdem die Tests abgeschlossen sind, erhalten wir einen Link, um unsere Regressionen zu überprüfen. Hier ist, was ich im Terminal bekommen habe

Und hier ist, was wir von Percy bekommen

Performance-Tests

• Level: Hoch
• Umfang: Testet die Anwendung auf Leistung und Stabilität.
• Mögliche Werkzeuge: Lighthouse, PageSpeed Insights, WebPageTest, YSlow

Performance-Tests sind großartig, um die Geschwindigkeit Ihrer Anwendung zu überprüfen. Wenn die Leistung für Ihr Unternehmen entscheidend ist – und das ist sie wahrscheinlich angesichts des jüngsten Fokus auf Core Web Vitals und SEO –, möchten Sie definitiv wissen, ob die Änderungen an Ihrem Codebase die Geschwindigkeit der Anwendung negativ beeinflussen.

Wir können dies in unseren restlichen Testablauf integrieren oder sie manuell ausführen. Es liegt ganz bei Ihnen, wie Sie diese Tests durchführen und wie häufig Sie sie ausführen. Einige Entwickler erstellen ein sogenanntes „Performance Budget“ und führen einen Test durch, der die Größe der App berechnet – und ein fehlgeschlagener Test verhindert eine Bereitstellung, wenn die Größe einen bestimmten Schwellenwert überschreitet. Oder testen Sie regelmäßig manuell mit Lighthouse, da es auch Leistungskennzahlen misst. Oder kombinieren Sie beides und integrieren Sie Lighthouse in die Testsuite.

Performance-Tests können alles messen, was mit Leistung zu tun hat. Sie können messen, wie schnell eine Anwendung geladen wird, die Größe ihres initialen Bundles und sogar die Geschwindigkeit einer bestimmten Funktion. Performance-Testing ist eine etwas breite, weite Landschaft.

Hier ist ein schneller Test mit Lighthouse. Ich denke, es ist ein guter Test, den man zeigen kann, da er sich auf Core Web Vitals konzentriert und auch so leicht in den Chrome DevTools zugänglich ist, ohne Installation oder Konfiguration.

Zusammenfassung

Hier ist eine Zusammenfassung dessen, was wir behandelt haben

Typ	Level	Umfang	Tooling-Beispiele
Einheit	Niedrig	Testet die Funktionen und Methoden einer Anwendung.	AVAJasmineJestKarmaMocha
Integration	Mittel	Testet Interaktionen zwischen Einheiten.	AVA Jest Testing Library
End-to-End	Hoch	Testet Benutzerinteraktionen in einem echten Browser, indem ihm Anweisungen und erwartete Ergebnisse bereitgestellt werden.	Cypress Puppeteer
Barrierefreiheit	Hoch	Testet die Benutzeroberfläche Ihrer Anwendung gegen Kriterien für Barrierefreiheitsstandards.	AccessLint axe-core Lighthouse pa11y
Visuelle Regression	Hoch	Testet die visuelle Struktur der Anwendung, einschließlich der visuellen Unterschiede, die durch eine Codeänderung entstehen.	Applitools Cypress Percy
Leistung	Hoch	Testet die Anwendung auf Leistung und Stabilität.	Lighthouse PageSpeed Insights WebPageTest YSlow

Also, ist Testen für jeden etwas? Ja, das ist es! Angesichts all der verfügbaren Bibliotheken, Dienste und Werkzeuge, mit denen wir verschiedene Aspekte einer Anwendung zu verschiedenen Zeitpunkten testen können, gibt es mindestens etwas da draußen, das es uns ermöglicht, Code gegen Standards und Erwartungen zu messen und zu testen – und einige davon erfordern nicht einmal Code oder Konfiguration!

Meiner Erfahrung nach vernachlässigen viele Entwickler das Testen und glauben, dass ein einfaches Durchklicken oder eine nachträgliche Überprüfung hilft, mögliche Fehler nach einer Codeänderung zu vermeiden. Wenn Sie sicherstellen möchten, dass Ihre Anwendung wie erwartet funktioniert, für so viele Menschen wie möglich inklusiv ist, effizient läuft und gut gestaltet ist, dann muss Testen ein Kernbestandteil Ihres Workflows sein, egal ob es automatisiert oder manuell ist.

Jetzt, da Sie wissen, welche Testarten es gibt und wie sie funktionieren, wie werden Sie das Testen in Ihre Arbeit integrieren?