Behavior Driven Development mit CakePHP, Django, Drupal und Symfony
In einen Workshop zum großen Treffen der Frankfurter Usersgroups, FUxCon 2013, haben wir einen Vergleich der vier Web Frameworks CakePHP 2, Django 1.5, Drupal 7 und Symfony 2 präsentiert. Ziel war es, die unterschiedlichen Ansätze der vier Frameworks zu vergleichen und gleichzeitig Behavior Driven Development vorzustellen.
Grundlage des Vergleichs war eine einfache Portfolio-Website. Diese besteht aus einer Startseite mit großem Textblock und darunter einer Projektliste. Der Startseite folgen über eine Paginierung am Seitenfuß weitere Seiten mit Listen von Projekten. Jeder Projekteintrag zeigt Titel, Anrißtext und ein kleines Foto. Zwischen den Seiten kann hin und her geblättert werden. Von den Projektlisten gelangt man per Klick auf den Projekttitel oder das Foto auf Detailseiten der Projekte mit großem Foto, Themenliste, Titel und Beschreibung. Die Beschreibung wird von unterschiedlichen Redakteuren in Markdown verfasst. Die Bilder sind automatisch auf die jeweils benötigten Großen skaliert - 200x200px auf den Listenseiten, 380x380px auf den Projektdetailseiten. Nichts Besonderes also. Hier ist ein Product Canvas für diese Seite:
Diese Portfolio-Seite sollte in allen vier zu vergleichenden Frameworks realisiert werden. Um die Implementierungen vergleichen zu können, haben wir das Verhalten formalisiert erfasst und dazu die Domain Specific Language (DSL) Gherkin genutzt. Verhaltensbeschreibungen in Gherkin sind im Grunde die aus der agilen Software-Entwickling bekannten User Stories, welche in einem agil entwickelten Projekt typischerweise vom Product Owner erfasst werden. Diese Rolle wird oft von Nichttechnikern bekleidet, daher sind Sprachkonstrukte in Gherkin einer natürlichsprachigen Ausdrucksweise angelehnt.
In Gherkin formulierte User Stories werden dort als Features bezeichnet. Features werden durch Fallbeispiele (sogenannte Szenarien) konkretisiert. Zur Validierung werden Szenarien eins zu eins mit Schrittdefinitionen unterlegt. Schrittdefinitionen entsprechen den Tests im klassischen, funktionalen Testen. Das besondere an Behavior Driven Development (BDD) ist, dass Szenarien zunächst ebenfalls in der DSL Gherkin geschrieben werden und so für Nichttechniker nachvollziehbar sind. So wird die Lücke zwischen Anforderungsdefinition und Softwareerstellung geschlossen.
BDD, also die Vorgehensweise, Verhalten für ein Software-Projekt formal zu beschreiben und validierbar zu machen, wurde bereits 2003 von Dan North aus dem damals noch recht jungen Test Driven Development entwickelt. Dan North entwickelte für seine Methode zunächst ein Werkzeug in Java. Inzwischen erfreut sich besonders das Ruby-Werkzeug Cucumber großer Beliebtheit, dem auch die DSL Gherkin entstammt.
Für PHP gibt es seit einiger Zeit mit Behat ebenfalls eine Implementierung. Wir haben Behat für unsere Verhaltensbeschreibungen und Tests genutzt. Alle vier Implementierungen erfüllen bereits das oben beschriebene Verhalten. Sie unterscheiden sich allerdings noch in einigen Details. Das Ziel, dass alle Vier auch formal testbar alle Szenarien gleichermassen erfüllen, ist also noch nicht ganz erreicht.
Alle vier Impementierungen sind mit ihren Aspekten Installation, Konfiguration, Modellierung, Geschäftslogik, Gestaltung, Nutzerkonten und Rechte, Themenlisten, Bild-Upload und Skalierung, Bearbeitungsmasken, Textformatierung und Testdatengenerierung ausführlich dokumentiert und stehen unter der General Public Licence (GPL) zum Ausprobieren und Weiterentwickeln als Github-Repository und als virtuelle Appliance zum freien Download zur Verfügung. Auch die Verhaltensbeschreibungen, Szenarien und Schrittbeschreibungen liegen frei verfügbar auf Github. Einstiegspunkt für das Projekt ist die Website cocomore.github.io/fuxcon2013. Wir freuen uns über Kommentare, Verbesserungsvorschläge, Pull-Requests oder auch Implementierungen in weiteren Frameworks.
