© Liashko/Shutterstock.com
Entwickler Magazin
Testen von AngularJS-basierten Web-Apps per Browserautomatisierung

Cross-Plattform-End-to-End-Testing

Stellen Sie sich den Moment vor, wenn Sie Ihre neue Webapplikation Ihren Kunden zur Verfügung stellen: Die App erstrahlt im Glanze neuer Features und präsentiert ihre neue Oberfläche. Kurz nach dem Release erhalten Sie das erste Feedback. Doch es fällt nicht so aus, wie Sie es erwartet haben. Dem Benutzer fällt auf, dass für manche Features zwar ein Button vorhanden ist, allerdings passiert nichts, wenn dieser angeklickt wird. Mit Schweißperlen auf der Stirn fällt Ihnen ein, dass Sie gestern Nacht eben diesen Button noch auf die Oberfläche gesetzt haben, ohne ihn wirklich mit dem hinter dem Feature liegenden Code zu verbinden.

Manuel Rauber


Im Artikel zuvor haben Sie Unit Tests kennengelernt. Unit Tests beschreiben das isolierte Testen einzelner Komponenten. Abhängigkeiten werden über Mocks ausgehebelt, um die Isolation zu ermöglichen. Bei einem End-to-End-Test (oder auch Systemtest; kurz e2e-Test) entfällt die Isolation. Das bedeutet, dass das gesamte System getestet wird (Abb. 1). Es spielt dabei keine Rolle, ob eine Komponente eine Datenbank, einen Webserver, ein Dateisystem oder eine grafische Oberfläche repräsentiert. Alle Komponenten werden mit diesem Test angesprochen und durchgetestet. Es ist so, als würde Ihr Kunde die Software benutzen. Die Schritte, die ein Kunde ausführen kann, werden beim e2e-Test automatisiert über ein Framework ausgeführt. Das bedeutet allerdings, dass man oft nur den positiven Fall testet, da man sonst gezielt Fehler in seine Anwendung einbauen muss, was sehr aufwändig werden kann. Zudem sollten solche Fehlerfälle bereits durch Unit Tests abgedeckt werden.

Abb. 1: Schematische Darstellung eines End-to-End-Tests

Viele Entwicklungsumgebungen bringen ein Framework mit, um e2e-Tests zu ermöglichen. In Visual Studio kann ein Coded UI Test [1] benutzt werden, um .NET-Applikationen zu testen. Allgemeiner kann auch AutoIt [2] eingesetzt werden, um automatisierte Eingaben zu ermöglichen. Im Web bietet sich Selenium WebDriver [3] an (im Verlauf des Artikels nur noch als Selenium bezeichnet), das sich auf Browserautomatisierung spezialisiert hat. Egal mit welchen Hilfsmitteln die Tests entwickelt werden, eines haben alle Tests gemeinsam: Spezifikationen.

Testspezifikationen

Ähnlich den Unit Tests benötigen auch e2e-Tests eine Spezifikation, die durch einen Test Runner ausgeführt werden kann. In einer Spezifikation wird definiert, in welcher Reihenfolge Buttons geklickt oder Eingabefelder gefüllt werden und wie die Anwendung darauf reagieren sollte. Auf jede Aktion folgt eine Reaktion. Diese Reaktion bestimmt letztendlich, ob wir den Test als Erfolg oder Misserfolg einstufen können.

Es existieren verschiedene Arten, wie diese Spezifikation geschrieben werden kann. Eine Art haben wir bereits bei den Unit Tests kennengelernt: Beschreibung durch Code. Code beschreibt, was bei den Tests passieren soll und was erwartet wird. Das bedeutet, dass man der Programmiersprache mächtig sein muss, um einen Test zu entwickeln. Neben der Beschreibung durch Code existiert auch eine textuelle Beschreibung: Gherkin [4]. Gherkin ist eine menschenlesbare, domainbeschreibende Syntax zum Beschr...

Entwickler Magazin
Testen von AngularJS-basierten Web-Apps per Browserautomatisierung

Cross-Plattform-End-to-End-Testing

Stellen Sie sich den Moment vor, wenn Sie Ihre neue Webapplikation Ihren Kunden zur Verfügung stellen: Die App erstrahlt im Glanze neuer Features und präsentiert ihre neue Oberfläche. Kurz nach dem Release erhalten Sie das erste Feedback. Doch es fällt nicht so aus, wie Sie es erwartet haben. Dem Benutzer fällt auf, dass für manche Features zwar ein Button vorhanden ist, allerdings passiert nichts, wenn dieser angeklickt wird. Mit Schweißperlen auf der Stirn fällt Ihnen ein, dass Sie gestern Nacht eben diesen Button noch auf die Oberfläche gesetzt haben, ohne ihn wirklich mit dem hinter dem Feature liegenden Code zu verbinden.

Manuel Rauber


Im Artikel zuvor haben Sie Unit Tests kennengelernt. Unit Tests beschreiben das isolierte Testen einzelner Komponenten. Abhängigkeiten werden über Mocks ausgehebelt, um die Isolation zu ermöglichen. Bei einem End-to-End-Test (oder auch Systemtest; kurz e2e-Test) entfällt die Isolation. Das bedeutet, dass das gesamte System getestet wird (Abb. 1). Es spielt dabei keine Rolle, ob eine Komponente eine Datenbank, einen Webserver, ein Dateisystem oder eine grafische Oberfläche repräsentiert. Alle Komponenten werden mit diesem Test angesprochen und durchgetestet. Es ist so, als würde Ihr Kunde die Software benutzen. Die Schritte, die ein Kunde ausführen kann, werden beim e2e-Test automatisiert über ein Framework ausgeführt. Das bedeutet allerdings, dass man oft nur den positiven Fall testet, da man sonst gezielt Fehler in seine Anwendung einbauen muss, was sehr aufwändig werden kann. Zudem sollten solche Fehlerfälle bereits durch Unit Tests abgedeckt werden.

Abb. 1: Schematische Darstellung eines End-to-End-Tests

Viele Entwicklungsumgebungen bringen ein Framework mit, um e2e-Tests zu ermöglichen. In Visual Studio kann ein Coded UI Test [1] benutzt werden, um .NET-Applikationen zu testen. Allgemeiner kann auch AutoIt [2] eingesetzt werden, um automatisierte Eingaben zu ermöglichen. Im Web bietet sich Selenium WebDriver [3] an (im Verlauf des Artikels nur noch als Selenium bezeichnet), das sich auf Browserautomatisierung spezialisiert hat. Egal mit welchen Hilfsmitteln die Tests entwickelt werden, eines haben alle Tests gemeinsam: Spezifikationen.

Testspezifikationen

Ähnlich den Unit Tests benötigen auch e2e-Tests eine Spezifikation, die durch einen Test Runner ausgeführt werden kann. In einer Spezifikation wird definiert, in welcher Reihenfolge Buttons geklickt oder Eingabefelder gefüllt werden und wie die Anwendung darauf reagieren sollte. Auf jede Aktion folgt eine Reaktion. Diese Reaktion bestimmt letztendlich, ob wir den Test als Erfolg oder Misserfolg einstufen können.

Es existieren verschiedene Arten, wie diese Spezifikation geschrieben werden kann. Eine Art haben wir bereits bei den Unit Tests kennengelernt: Beschreibung durch Code. Code beschreibt, was bei den Tests passieren soll und was erwartet wird. Das bedeutet, dass man der Programmiersprache mächtig sein muss, um einen Test zu entwickeln. Neben der Beschreibung durch Code existiert auch eine textuelle Beschreibung: Gherkin [4]. Gherkin ist eine menschenlesbare, domainbeschreibende Syntax zum Beschr...

Neugierig geworden?


   
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang