Automatisches Testing für TYPO3 – Codeception-Schulung bei UEBERBIT

Kurz vor Ostern nahmen wir, das TYPO3-Team von UEBERBIT in Mannheim, an einem zweitägigen Workshop zum Thema Testing-Automatisierung teil, mit dem klar definierten Ziel: Wir wollen unsere bisherigen Testing-Verfahren deutlich verbessern. Die Frage ist nur: Wie? Antworten auf diese und viele weitere Fragen wollte Roland Golla von der Entwicklungshilfe NRW mit uns zusammen erarbeiten.

Aber bevor wir uns das Wie anschauen, haben wir uns erstmal einer mindestens genauso wichtigen Frage gewidmet:

Warum sollte man überhaupt das Testing automatisieren?

Um diese Frage zu beantworten, haben wir uns zu Beginn des Workshops unsere aktuellen Testing-Vorgänge angeschaut, potentielle Fehlerquellen analysiert und über verschiedene Strategien und Verfahren zur Automatisierung unseres Testings gesprochen.
Es ist eine Frage die uns Entwicklern immer wieder begegnet. Nach zwei Tagen Workshop lautet die Antwort für uns:

Menschen machen Fehler. Automatisierung kann dies zwar nicht verhindern, aber deutlich reduzieren.

Außerdem ist das „Scoping“ einer Änderung, sprich die globale Auswirkung auf den gesamten Code, einfach nicht ohne eine durchdachte Testumgebung ausreichend überprüfbar. Es gibt gute Gründe, warum automatisiertes Testing die Grundlage für „Refactoring“ ist bzw. sein sollte.
Seitdem ist für uns klar:

(Automatisiertes) Testen kann nicht, Testen muss!

Wir können nicht nur Test schreiben, wir MÜSSEN es.

Der Weg ist das Ziel – Das Ziel ist der Weg – Testing TYPO3 Extension

Auf das Wie gab es sehr bald auch schon eine durchaus zufriedenstellende Antwort: Das Codeception-Framework.
Da sowohl Frontend- als auch Backend-Entwickler bei uns zukünftig automatische Tests schreiben werden, bietet sich dieses Framework für unser Team aufgrund seiner Vielfalt an Testmöglichkeiten gut an. Auch die für uns Frontend-Entwickler nicht so häufig verwendete Sprache PHP stellt aufgrund bekannter Programmierparadigma keine wirkliche Hürde dar.Außerdem vorteilhaft: Codeception ist in TYPO3 integriert.

Im Workshop wurde der Hauptfokus auf End-to-End-Testing (E2E), auch Acceptance-Tests genannt, gelegt. Dabei geht es um das Testen des Frontends und der User Interaktion auf einer Seite. Dennoch haben wir auch über Unit- und API-Testing gesprochen, worauf ich aber in diesem Beitrag nicht weiter eingehen werde.

Nachdem wir mit einem großen Teil der Theorie durch waren, zeigte uns Roland exemplarisch an seinem Mac, wie wir das Framework zusammen mit dem dafür benötigten Selenium-Server installieren und für unsere Projekte und Infrastruktur anpassen können.

Dann haben wir gemeinsam anhand einer User-Story Schritt für Schritt unseren ersten Test erarbeitet. Dieser hat die Aufgabe, ein Input-Feld in einem Widget auszufüllen und anschließend das zurückgegebene Ergebnis zu überprüfen.

Wie man Akzeptanzkriterien testet

Ein Cest (Codecept + Test ?) folgt dabei grundsätzlich immer einem ähnlichen Muster (hier vereinfacht dargestellt):
Dazu definieren wir zunächst die Elemente, sowie die Selektoren dafür mit denen wir interagieren wollen. Dies kann je nach Test-Framework durch CSS- oder XPath-Selektoren erfolgen. Generell bietet es sich an, hierfür spezielle `data-qa`-Attribute zu verwenden um Kollisionen mit dem Markup zu vermeiden.

Anschließend beschreiben wir was unser WebDriver, ein ferngesteuerter Browser nach W3C-Standards, der Reihe nach zu tun hat. Dies beginnt mit einer Navigation zur entsprechenden Seite.In der Hauptfunktion definieren wir dann, welche Interaktion mit dem Browser stattfinden soll.Im folgenden Beispiel wählen wir im Dropdown-Menü das erste Element und lesen dessen Wert aus.Durch eine Assertion-Evaluierung wird dann verglichen, ob der vorhandene Wert mit dem erwarteten Wert übereinstimmt. Erst danach ist der Test als erfolgreich zu betrachten. Ist dies nicht der Fall, schlägt der Test fehl.

Grundsätzlich gilt:

Tests sollten durchdacht sein. Ein unüberlegter Test bringt keinem etwas.
Fertige Tests werden und sollten idR. auch nicht mehr angefasst werden müssen. Schließlich dienen sie als Blaupause zum Verbessern von unserer Software.

Zurück zu unserem Testing

Endlich kam der entscheidende Moment.
Der Browser öffnet sich. In Sekundenschnelle wird auf die entsprechende Seite navigiert und unser Input-Feld wird wie erwartet ausgefüllt und…
Zack: Der Test schlägt fehl.

*Hmm.*

Also wieder zurück in die Testanweisung und noch einmal versuchen. Der Fehler ist schnell gefunden. Der Test wird grün und wir wollen endlich selber unser Glück versuchen.

Und schon wurde es ernst: Der Reihe nach haben wir mithilfe der originalen NeverCodeAlone-Funktastatur^tm dem Projekt einen weiteren Test hinzugefügt. Somit kam jeder von uns Mal dran und wir unterstützten uns gegenseitig als Team.

Am Ende des Tages haben wir dann in Zweier-Teams per Los bestimmte User-Stories zugeteilt bekommen und diese auf unseren lokalen Umgebungen durch Tests abgebildet. Tatsächlich ging dies zu diesem Zeitpunkt schon ziemlich gut von der Hand. Und auch das Gefühl, wenn der eigene Test erfolgreich vor deinen Augen durchgeführt wird, ist wirklich sehr befriedigend 😀

Als wir am nächsten Tag alle Tests zusammen geführt haben, merkten wir, wo noch Potential zur Verbesserung für künftige Tests ist und was schon gut funktioniert.

Fazit TYPO3 Testing mit Codeception

Am Ende der zwei Tage wussten wir nicht nur, warum wir unsere Testing-Verfahren automatisieren sollten, sondern auch wie. Sämtliche Fragen wurden geklärt, nebenbei haben wir auch noch den ein oder anderen grundsätzlichen Tipp für das tagtägliche Arbeiten mit dem Terminal und unseren IDEs mitnehmen können.

Tatsächlich ist das Ganze weitaus weniger Magie als die durchaus faszinierende Ausführung der Tests vermuten lässt.Wichtig ist grundsätzlich vor allem eines: MACHEN! Und genau das werden wir jetzt auch tun. Denn noch wesentlich deutlicher (und diese Meinung wird jetzt auch von den Skeptikern unter uns geteilt) zeigt sich: Wir packen das an! Automatisiertes Testing @UEBERBIT ist ab sofort „the way to go“.

Und ganz ehrlich? Ich finds toll! ?

Shameless self promotion

Wer mehr von unserer Arbeit sehen und lesen will, kann gerne auf unserem Entwicker-Blog bitspeicher.blog vorbeischauen.
Dort gibt es aktuell auch einen sehr umfangreichen Beitrag über Prettier, ein automatisches Formatierungsprogramm für euren Code (gibt es auch für PHP-Code ?) welcher von meiner Wenigkeit verfasst wurde.
Wer noch mehr an Testing-Verfahren interessiert ist, schaut bei den Beiträgen von meinem Kollegen Daniel Ruf zum Thema Browser-Automatisierung mit Puppeteer sowie Unit-Testing mit Puppeteer vorbei.

Persönlich findet ihr mich auf Twitter unter @diverent2 sowie auf GitHub unter dem selben Namen. 🙂