Artikelserie Test: Codeception (FE/Acceptance, API, Monitoring)

In den ersten beiden Tests haben wir den Code geprüft und getestet. In diesem Teil wollen wir jetzt testen, welche Daten wirklich fließen und was Benutzer tatsächlich sehen.

• Zu Artikel 1: Linting, Stan, phpCS, Audit
• Zu Artikel 2: Unit, Functional, Coverage

Was Gurken mit Tests zu tun haben

Für alle folgenden Tests verwenden wir den gleichen Test-Code-Stack – wir verwenden Codeception als Testrunner und darin das Konzept von Behaviour Driven Testing, für welches die Sprache Gherkin (zu Deutsch Gurke) verwendet wird.

Wie man sehen kann, steht in dieser Syntax die Benutzerinteraktion im Vordergrund – es wird sehr selten mit CSS-Selektoren gerarbeitet, normalerweise wird ein Vorgang immer auf eine Art beschrieben, wie ein Benutzer die Anwendung verwenden würde.

Durch die eher einfach gehaltenen Schritte und den Fokus auf den tatsächlichen Inhalt der Website kann man sehr komplexe Abläufe abbilden – und wie bei den anderen Tests wird keine Logik versteckt. Man erkennt auch wieder AAA, wobei Act und Assert mehrmals in beliebiger Reihenfolge durchgeführt wird.

Acceptance für die Funktionen

Was wird dabei aber wirklich getestet? Im Beispiel-Code wird ein Acceptance-Test gezeigt. Dieser steuert einen Browser – wahlweise ein normaler Chrome-Browser mit allen Features oder ein Headless Chrome innerhalb eines Docker-Containers in der Entwicklungs- und CI-Umgebung – und klickt sich durch die fertige Anwendung. 

Acceptance-Tests sind bei uns so definiert, dass vor dem Testlauf ein definierter, in git abgelegter Datenbankstand importiert wird, der pro Test optional ergänzt werden kann, und anschließend wird der Test durchgeführt. Am Ende jedes Tests wird die Datenbank wieder auf den definierten Stand zurückgesetzt. Dadurch kann man beliebige Vorgänge beliebig häufig testen – beispielsweise eine Benutzer-Anlage. Wenn der Datenstand nicht immer gleich wäre, könnte der Test nur einmal durchgeführt werden, da ein User mit einem Benutzernamen nur einmal angelegt werden darf, und hätte man einen zweiten Test um den User zu löschen müsste man diese Tests immer nacheinander ausführen, damit man keine Inkonsistenzen verursacht.

Diese Tests testen immer den kompletten Anwendungsstack – Webserver-Config, Backend- und Frontend-Code, CSS (beispielsweise display: none hat Auswirkungen auf Testaufrufe wie „I should see“), Datenbank und Inhalte, der Inhalt des Dateisystems – you name it, you test it. Dabei muss man natürlich beachten, dass Tests, welche immer die Website oder -App rendern und mehrmals Klicken und Formulare ausfüllen und absenden entsprechend lange laufen können, weswegen man diese Tests normalerweise nicht als Hauptsache, sondern als Ergänzung zu anderen, schnelleren Tests verwendet. 

API-Testing in schneller

Unser größtes Projekt derzeit ist eine React-Anwendung mit einem TYPO3-Backend. Uns haben die Tests zu lange gedauert (selbst mit Parallelisierung und ähnlichem), vor allem wenn wir für verschiedene Berechtigungen und für nicht eingeloggte User die korrekte Daten-Sichtbarkeit prüfen wollten. Für diesen Zweck verwenden wir darum API-Tests, welche ebenfalls in Gherkin mit Codeception geschrieben werden, aber intern Guzzle verwenden. 

Diese Tests haben leicht andere Steps (Beispiel: „Given that the API is logged in as ‚user’“), wodurch Codeception so gesteuert wird, dass eben Guzzle die Befehle ausführt, und wir testen dann direkt die API-URLs, die Requests und Responses mit JSON-Aufrufen und die Datenbank-Inhalte. Der Vorteil – während einfache Acceptance-Tests wie Login mit Prüfung auf den Inhalt der Startseite 4 Sekunden benötigen, benötigt die API-Only-Stage für einen ähnlichen Test ein paar Millisekunden.

Unser Ablauf besteht häufig darin, dass die API die verschiedenen Fälle und Daten prüft (ohne Login, verschiedene Berechtigungen, gültige Daten, ungültige Daten, Daten aus der Vergangenheit/von Heute/aus der Zukunft usw.) und die FullStack-Tests dann prüfen, dass die Anwendung sich in einem Erfolgsfall und in einem Fehlerfall korrekt verhält. Außerdem testen wir im FullStack auch FE-eigene Funktionen wie z.B. dass Formularfelder sich unterschiedlich verhalten, je nachdem, was ein User ausfüllt.

Wir wollen Fehler sehen, bevor sie für den Kunden relevant werden

Außerdem verwenden wir Codeception und Gherking für eine dritte Testing-Suite. Die FullStack- und API-Tests werden immer auf jeden Commit und den Main-git-Stand ausgeführt, wenn Änderungen passieren, aber damit immer nur für den Stand auf der Entwicklungs-Umgebung. Mit der dritten Suite testen wir Funktionen direkt auf dem Livesystem des Kunden.

Auch hier verwenden wir den Browser und User-ähnliche Schritte, wir achten aber darauf, dass wir innerhalb der Tests keine Daten verändern, und dass wir nicht auf veränderbare Daten prüfen – beispielsweise Testen wir beim Aufruf einer Aktivität (wie oben im Beispielcode) nicht auf ein genaues Datum oder einen genauen Vor- und Nachnamen, sondern wir testen darauf, dass ein beliebiges Datum und ein beliebiger Name angezeigt werden – diese Info reicht uns, um zu wissen, dass unser Live-System den Inhalt korrekt rendert. 

Das Ziel dieser Tests besteht darin, dass wir nach Deployments oder nach nächtlichen Importern und ähnlichem wissen wollen, dass das Produktivsystem weiterhin funktioniert, und wenn nicht wollen wir die Info bekommen, bevor es Auswirkungen für tatsächliche Website-Benutzer gibt. In einem älteren Projekt gab es tatsächlich den Fall, dass wir durch Tests morgens gegen 8:00 Uhr wussten, dass es einen Fehler gibt – diesen konnten wir innerhalb von ein paar Minuten beheben, und als die Benutzer um 8:30 bis 9:00 Uhr angefangen haben, die Anwendung zu verwenden, konnten diese fehlerfrei arbeiten.

Verwendete Tools

Für die Übersetzung der Gherkin-Syntax in Codeception-Aufrufe gibt es im Codeception-Umfeld Methoden, die man selbst programmieren kann. Wir haben Standard-Steps, welche immer wieder verwendet werden, in diverse Composer-Pakete aufgeteilt und auf Github und Packagist veröffentlicht. Diese Repository befinden sich im Account/Vendor der punkt.de, inklusive einem kleinen Demo-Projekt, in welchem man die Verwendung nachlesen kann. 

Abschluss

Dies war der letzte Teil unserer Test-Reihe. Damit können nun Anwendungen getestet werden – von der Codequalität bis zur korrekten Funktionsweise auf dem Livesystem.

Agiles Testing und Prozess-Know-how für Ihr Team:

Egal ob Agentur, Industrieunternehmen oder ein eigenständiges Entwicklerteam: Wenn Sie agile Testing-Prozesse etablieren oder weiterentwickeln wollen, unterstützen wir Sie mit unserem Know-how – sei es durch praxisorientierte Workshops oder durch direkte, projektbezogene Mitarbeit. Wir begleiten Sie von der Einführung agiler Testmethoden über die Optimierung bestehender Abläufe bis hin zur Entwicklung und Umsetzung individueller Testing-Strategien. 

Sprechen Sie uns gerne an, um gemeinsam Ihre Qualitätssicherung und Entwicklungsprozesse auf ein neues Level zu heben!