TYPO3 Camp Rhein Ruhr 2015 – Recap 1: Wie man Funktionen automatisiert testet

Das Camp

Das Camp war wie jedes Jahr erneut ein tolles Ereignis. Gut Organisiert und in der tollen Location des Unperfekthaus.

Vielen Dank daher erneut an die Organisatoren des Camps, die Redner und Interessierten, sowie Sponsoren.

Im Mittelpunkt standen Barrieren die eingerissen werden sollten. So gab es einen Live Call zur T3EE. Daneben aber die klassischen Themen die man mit dem Begriff verbindet, wie Barriere Freiheit von Websites. Es wurde aber auch versucht die Barrieren für Integratoren und Frontendler in Themenbereiche zu verringern, zu welchen diese bisher weniger Zugang hatten.

Live Call zum T3EE

Der erste eigene Talk

So konnte ich meinen ersten Talk auf einem Camp halten, zum Thema Behat und Mink. Ziel war es nicht Programmierern, wie TYPO3 Integratoren, die Arbeit zu erleichtern und Zeit zu sparen. Der Talk war gut besucht und das Feedback im Anschluss sehr gut. So gab es reges Interesse und weitere Gespräche.

Ziel war es auch aufzuzeigen wie einfach automatisiertes Testing möglich ist und wie wenig Zeit hier investiert werden muss. Im Vergleich dazu gibt es schnell Ergebnisse die viel Zeit und somit Geld sparen.

Behat im Detail

Behat setzt, im Gegensatz zu anderen Frameworks zum Testen, beim schreiben der Tests auf die “Syntax” Gherkin auf. Diese ermöglicht es in einem eigenen Wortschatz, in der nativen Sprache wie Deutsch, Englisch, Französisch, …, die Tests zu schreiben. So können auch nicht “techies” sich die Arbeit des Testings vereinfachen und Zeit sparen. So kann ein Integrator beispielsweise testen, ob die eingebaute Registrierung mittels 3rd Party Extension auch wie gewünscht funktioniert. Oder ob der Kassenprozess in einem Magento Shop erfolgreich abgeschlossen werden kann.

Ein Test für einen funktionierenden Login sieht dann zum Beispiel so aus:

Ordner Struktur mit Beispiel Feature des Logins

Das Setup ist denkbar einfach, es wird lediglich minimales Können auf der Kommandozeile vorausgesetzt, welches vermutlich in ein Paar Jahren durch Composer im TYPO3 Umfeld ohnehin notwendig wird.
Um erste Erfahrungen zu erhalten, folgt einfach der Anleitung auf unserem Github Repository. Bei Problemen kontaktiert einfach mich auf dem Weg eurer Wahl, ob E-Mail, Twitter, Slack, …

Der Ausblick

Gleichzeitig Dokumentation und Anforderungsbeschreibung

Durch die Schreibweise der Tests bietet Behat noch viele weitere Vorteile im Vergleich zu anderen Frameworks. Schaut man sich die Tests einmal an, so stellen diese neben dem Test auch direkt eine Dokumentation dar. Sie beschreiben den Funktionsumfang und die Funktionsweise der einzelnen Komponenten einer Webseite. So dienen sie neben dem Testing auch der Anforderungsbeschreibung.

Ermöglicht BDD ohne großen Mehraufwand

Hier kann ein Kunde in ähnlicher Weise die Anforderungen schreiben, z.B. der Product Owner in Form von Userstories, welche dann vom Entwickler nur noch leicht angepasst werden müssen. Somit wird ohne viel Aufwand, die Stories werden ohnehin definiert, direkt BDD (=Behaviour Driven Development) ermöglicht.

Zudem ist die Ausgabe der Tests für den Kunden lesbar. Somit gibt es eine hilfreiche Dokumentation was in welchem Umfang getestet wurde, und mit welchem Ergebnis. Dies in Textform oder weiteren gängigen Formaten.

HTML Report von Behat

Bietet visuelle Ausgabe mit Screenshots

So kann Behat auch erweitert werden, so dass im Fehlerfall direkt Screenshots abgelegt werden. So wird dokumentiert wie sich die Fehler im Frontend auswirken.

Es können aber nicht nur Screenshots im Fehlerfall erstellt werden. Es gibt auch die Möglichkeit jeden einzelnen Schritt als Screenshot festzuhalten. Die erstellen Screenshots können abgelegt werden und so für spätere Tests als Vergleich genutzt werden.
Heraus kommt dann ein Overlay welches die visuellen Unterschiede hervorhebt.

Darstellung von visuellen Unterschieden

Auch Integration in Workflows ohne Probleme möglich

Eines der möglichen Ausgabeformate ist auch junit welches von Automatisierungstools wie Bamboo ausgewertet werden kann. Somit ist die einfache Integration in die Workflows während der Entwicklung ohne Umstände möglich. Jede Anpassung wird automatisch getestet. Gibt es einen Einbruch in der Funktionsweise der Webseite, so wird der Entwickler informiert und kann diese beheben ehe seine Anpassungen integriert werden.

Cross-Browser Testing einfach möglich

Es kann aber nicht nur die reine Funktionsweise der Webseite getestet werden, sondern konkret die gleiche Funktion in allen gängigen Browsern. Somit wird sichergestellt das die gleichen Funktionen in allen Browsern, ob IE, FireFox, Google Chrome, Safari, oder auch mobil wie iOS und Android, gegeben sind. Dies wird durch Verwendung von [Selenium Grid][] ermöglicht. Dieses stellt die Schnittstelle zu den einzelnen Browsern in Virtuellen Maschinen her und ermöglicht es so die Tests gegen alle Browser laufen zu lassen.

Mit GUI für nicht Entwickler

Derzeit gibt es auch eine Webgui für nicht Entwickler um Tests einfacher zu schreiben und auszuführen. Dennoch scheint es für viele Nicht-Entwickler dennoch eine hohe Hürde zu sein. Hier kann man also noch in die Bresche springen und ein natives Programm für Windows und Mac OS X schreiben welches die Funktionalitäten einfacher zur Verfügung stellt.

Fazit

Der Einsatz ist mit so geringem Aufwand möglich das dies jeder einmal probieren sollte. Der Nutzen wird direkt sichtbar. Zudem gibt es langfristig weitere Möglichkeiten der Nutzung welche man nach und nach für sich erschließen kann.

Daher möchten wir Jedem Interessierten nahelegen sich an dem Github Repository zu versuchen.