Behat Low Poly

Behat Tests auf Drupal Systemen

Ich möchte in diesem Blogbeitrag kurz zusammenfassen was ein Behat Test ist, wie ein Behat Test aufgebaut ist und wie man ganz grob so einen Test implementiert.

Was sind Behat Tests?

Nicht nur in Drupal Projekten kommt es vor, dass neuer Code Fehler aufweisen kann. Das kann z.B. schnell passieren wenn der Entwickler nach dem Testen noch eine kleine Unschönheit im Code bemerkt und diese vermeintlich korrigiert ohne Änderungen an der Funktionalität zu machen, aber aus Zeitgründen nicht noch einmal testet. Noch schwerer ohne Tests abzudecken ist, wenn der neue Code versehentlich nicht nur Änderungen an der gewünschten Stelle verursacht sondern, alte Funktionalität verändert. Denn wer hat schon Zeit nach jeder Änderung alle Funktionalitäten in dem Projekt zu testen? Genau deshalb sollen automatische Tests überprüfen ob der neue Code seinen Zweck erfüllt und auch keine unbeabsichtigten Änderungen an der bisherigen Funktionalität macht.

Der große Vorteil von Tests ist, dass man sie automatisiert ausführen kann und somit im Endeffekt Zeit sparen kann und nebenbei noch Seiteneffekte frühzeitig erkennen kann.

Behat Tests sind Teil des Behavior-Driven Developments (BDD) und basieren darauf, dass man das testet, was auch die Nutzer tun würden. Genauer wird in Behat Tests eine Userstory in Text form festgehalten, die beim ausführen des Tests automatisch durchgeführt wird. Ob der Test erfolgreich ist oder nicht, hängt von den angegeben Erwartungen ab.

Wie sieht ein Behat Test aus?

Behat Tests werden in Gherkin geschrieben. Die konkreten Testabläufe werden in verschiedene Features gegliedert. Diese Features sollen ungefähr eine Funktionalität der Webseite abdecken. Verschiedene Userstories werden in so genannte Scenarios gegliedert. Ein einfaches Beispiel wäre:

Feature: basic functionallity # Dieser Test prüft ob der Aufruf der Webseite einen # 200er response code (=Erfolgreich) liefert. Scenario: Working homepage Given I am on the homepage Then I should get a "200" HTTP response # Dieser Test prüft ob auf der Webseite ein body # element vorhanden ist. Scenario: Markup on homepage Given I am on the homepage Then I should see an "body" element

Sowohl die Namen der Szenarien als auch der Features haben keine Auswirkungen auf den Testablauf und dienen nur der Übersicht und Verständlichkeit.

Hier eine kleine Übersicht über die wichtigsten Schlüsselwörter eines Behat Tests:

Given - Ausgangspunkt für die Userstory / Wo soll etwas passieren.
When - Was soll gemacht werden? z.B. Fülle in das Registrierungsformular folgende werte...
Then - Was soll geschehen / Worauf soll geprüft werden?
And - Ein weiteres When/Given/Then

Wie schreibe ich einen Behat Test?

Am besten ist es, wenn man den Test mit schon vorhandenen Sätzen ausdrücken kann um eine Liste von möglichen Sätzen zu erhalten kann mann durch


behat -dl

erhalten. Sollte das nicht möglich sein, so kann man den Test trotzdem erst einmal mit Sätzen schreiben, die man anschließend implementiert.

Scenario: Working homepage Given I am on the homepage and i am drunk Then I should get a "200" HTTP response

Sehr praktisch dabei ist, dass der Test schon ausgeführt werden kann. Und beim Ausführen gleich der nötige Code um die Funktion zu implementieren ausgegeben wird:

You can implement step definitions for undefined steps with these snippets: /** * @Given /^I am on the homepage and i am drunk$/ */ public function iAmOnTheHomepageAndIAmDrunk() { throw new PendingException(); }

kopiert man diesen Code in die featureContext.php so sorgt der Wurf der PendingException dafür, dass der Test als "pending" gewertet wird und der Test weiterhin gelb markiert bleibt. Nun muss "nur" noch die passende Logik implementiert werden.

Um einen Fehler zu schmeißen kann man einfach


throw new \Exception('Explenation...');

verwenden. Um beispielsweise innerhalb der Implementierung eines Then Schritts einen anderes Then zu verwenden kann man ein neues Objekt erstellen:


Step\Then('the "style" element should contain ".css"');

Dieses wird dann als ganz normaler Schritt beim Ausführen des Tests aufgelistet.

Komplexität der Tests

Behat Tests sollten wichtige Funktionalität des Projekts abdecken wie z.B. "können anonyme Benutzer auf das Registrierungsformular?", "Bekommen sie nach abschicken des Registrierungsformulars eine E-Mail mit Aktivierungslink?", "werden sie beim aufrufen des Aktivierungslinks auch entblockt?".

Behat Tests sind nicht unbedingt dafür geeignet, um alle Möglichkeiten abzudecken, was Nutzer in einem bestimmten Fall tun könnten. Wenn es z.B. darum geht um zu testen, ob bei einer Länderauswahl auch nur die zugehörigen Postleitzahlen valide Eingaben sind, ist das eher ein Anwendungsfall für einen YSimpleTest. Es muss also immer ein sinnvoller Kompromiss gefunden werden zwischen der Abdeckung des Tests und dem nötigen Aufwand den Test zu schreiben.

Am Ende möchte ich eine Übersicht über wichtige Anlaufstellen für Dokumentation und Beispiele machen:

Projektseite http://behat.org/
Gute Anlaufstelle für die Installation von behat und grundlegende Verwendung von behat.

Drupalextension https://github.com/jhedstrom/drupalextension
Projektseite der Drupalextension mit Dokumentation.

Tags

behat