Wie wir Behat-Tests zur Spezifikation und Qualitätssicherung in Projekten einsetzen
In diesem Beitrag
Im hat Sebastian beschrieben, dass jede einzelne Codeänderung bei uns durch die Ausführung von automatisierten Tests überprüft wird. Diese Tests sind ein wesentliches Werkzeug, um die Qualität in unseren Projekten dauerhaft sicherzustellen. Softwareprojekte entwickeln sich stetig weiter – neue Features kommen hinzu, bestehende Teile werden überarbeitet. Ohne ein verlässliches Testsystem besteht bei jeder Änderung das Risiko, dass sich unbemerkt Fehler einschleichen. Tests helfen uns, das zu vermeiden.
Automatisierte Tests als Grundlage der Qualitätssicherung
Automatisiert“ bedeutet, dass das Testprogramm innerhalb weniger Minuten abläuft, ohne dass manuelle Schritte erforderlich sind. Nur so lassen sich die Tests häufig ausführen. Fehler können damit in der laufenden Entwicklung erkannt und korrigiert werden, nicht erst in einer späten Qualitätssicherungs- oder Abnahmephase.
Der Inhalt der Tests ist natürlich sehr projektspezifisch. Tests für einzelne, kleine Abschnitte der Software werden Unit Tests“ genannt und oftmals direkt vom Entwicklungsteam parallel zum eigentlichen Anwendungscode geschrieben. In diesem Artikel geht es speziell um eine weitere Art von Tests, die auf der Idee des basieren.
Behaviour Driven Development
Das Ziel von BDD ist es, durch enge Zusammenarbeit zwischen dem Entwicklungsteam und der fachlichen Seite (z. B. dem Auftraggeber) ein gemeinsames Verständnis des gewünschten Verhaltens der Software zu erreichen. Der Fokus liegt dabei nicht auf den Details der technischen Umsetzung, sondern auf dem Verhalten der Anwendung aus fachlicher Sicht oder Sicht der Endnutzer.
Beschreibung von Anforderungen in „Gherkin“
Die Anforderungen werden dazu in einer einer halb-strukturierten Schreibweise formuliert, die genannt wird. Diese Notation lässt sich auch ohne technisches Hintergrundwissen lesen und verstehen.
Hier ein Beispiel aus der , in der Trainer berufliche Profile hinterlegen und sich miteinander vernetzen können.
Scenario: Reviewing pending connection requests on the dashboard Given my trainer profile was set up And another trainer was added and activated And they submitted a request to connect professionally with me And I am logged in When I go to my incoming connection requests page Then I should see the trainers name And I should see "Approve" And I should see "Refuse"
Typisch für die Beschreibungen ist die given-when-then“-Struktur. Jedes Szenario definiert zuerst eine Ausgangsbasis oder die Voraussetzungen, die für ein bestimmtes Verhalten gegeben sein müssen. Die when“-Phase beschreibt dann eine vom Benutzer, durch ein Ereignis o. ä. ausgelöste Aktion oder einen Ablauf. Das abschließende then“ überprüft, ob die Veränderungen und Ergebnisse so eingetreten sind, wie sie gewünscht werden.
Behat interpretiert Szenarien als Drehbuch für einen Softwaretest
Die Formulierung ist strukturiert genug, um als Drehbuch“ eines automatisierten Tests abgearbeitet zu werden. Für die Umsetzung mit der Programmiersprache PHP setzen wir das Tool Behat“ ein. Behat fungiert als Bindeglied zwischen den in Gherkin geschriebenen Szenarien und der Ausführung von PHP-basiertem Anwendungs- und Testcode. Dazu werden Teilsätze oder Schablonen“ mit dem Programmcode verknüpft, der dann – getrieben von der textlichen Spezifikation – abgearbeitet wird.
Idealerweise lassen sich Anforderungen so zumindest in Grundzügen bereits während der Konzeption eines Features festhalten. Während der Umsetzung wird dann auch die Ausführung als Test ermöglicht, womit unmittelbar die Ergebnisse validiert werden können. Dabei entwickelt sich sehr bald ein projektspezifisches Vokabular und ein Grundgerüst von (Halb-)sätzen. Es wird zunehmend einfacher, auch neue Szenarien und Anforderungen zu beschreiben.
Einsatz auf verschiedenen Ebenen der Software
Die Behat-Tests lassen sich in unterschiedlichen Ebenen der Software einsetzen. Hier ein Beispiel für einen Test des Modells“ einer Software. Mit Modell werden die zentralen Komponenten eines Systems bezeichnet, in denen unmittelbar die relevanten, projektindividuellen Konzepte, Dinge und Umstände abgebildet werden.
Szenariogrundriss: Status eines Nutzenbewertungsverfahrens Angenommen es gibt ein Nutzenbewertungsverfahren Und das Nutzenbewertungsverfahren hat den Zustand ZUSTAND_AKTIV Und das Nutzenbewertungsverfahren beginnt das Stellungnahmeverfahren am <Beginn> Und das Nutzenbewertungsverfahren hat eine Frist zur Abgabe einer Stellungnahme bis zum <Ende> Dann sollte sich das Nutzenbewertungsverfahren im Status <Status> befinden Beispiele: | Beginn | Ende | Status | | gestern | | STATUS_BEWERTUNG_GESTARTET | | morgen | +9 Tage | STATUS_BEWERTUNG_GESTARTET | | gestern | morgen | STATUS_STELLUNGNAHMEFRIST_LAEUFT | [...]
Wie man sieht, lassen sich Szenarien auch in deutscher Sprache formulieren, wenn das die bevorzugte Sprache aller Projektbeteiligten ist.
Szenarien können auch beschreiben, wie Benutzer:innen mit einer Webanwendung interagieren. Es können beispielsweise Eingaben in ein Formular gemacht oder Elemente der Bedienoberfläche angeklickt werden. So beschreibt das folgende Szenario, wie eine Projektleiterin in der eine Nachricht an einen Projektteilnehmer schicken kann:
Scenario: Sending a message to a learner Given I am on the"Communications" page When I fill in "hello" into the "Your message" field And I press "Submit message" Then I should be on the "Communications" page And I should see "Your messagewas sent to the participant." And I should see "hello" in the"communication history" section
Es ist sogar möglich, zur Ausführung dieser Tests einen ferngesteuerten“ Webbrowser zu verwenden. Damit werden Ende-zu-Ende“-Tests möglich, bei denen auch die korrekte Funktionsweise solcher Teile mit überprüft werden kann, die im Browser des Benutzers ablaufen.
Dazu als letztes Beispiel die Spezifikation einer Autocomplete“-Komponente, die eingesetzt wird. Sie ist in JavaScript geschrieben und schlägt direkt während der Eingabe der ersten Zeichen in ein Eingabefeld mögliche Suchworte vor.
Szenario: Filtern von Nutzenbewertungsverfahren über Suchworte Angenommen es gibt ein Nutzenbewertungsverfahren Und das Nutzenbewertungsverfahren hat als Handelsnamen "Quxdoo" Und das Nutzenbewertungsverfahren hat als Suchwort "Findolimod" Wenn ich die Listenseite der Nutzenbewertungsverfahren aufrufe Und ich gebe "Fin" in das Feld "Wirkstoff oder Handelsname" ein Und ich drücke "Filter anwenden" Dann sollte ich "Quxdoo" im Element "HTML: Auflistungstabelle" sehen
Wie viel Aufwand macht die Einrichtung von Behat-Tests?
Ohne Frage ist das Schreiben der Gherkin-Spezifikationen, der dazu notwendige Testcode und die erstmalige Einrichtung und Integration in die Test-Pipeline mit etwas zusätzlichem Entwicklungsaufwand verbunden.
Die Basiseinrichtung lässt sich in der Regel im Rahmen eines Personentags erledigen. Etwas mehr Aufwand stellt die tatsächliche Umsetzung der ersten Szenarien dar, weil zu Anfang ein „Grundvokabular“ für das Projekt aufgebaut werden muss. Je nach Umfang und Komplexität eines zu entwickelnden Features kann es dabei durchaus sein, dass zu Beginn 25% oder mehr der Entwicklungszeit für die Umsetzung des Test-spezifischen Codes benötigt werden.
Wir haben aber beobachtet, dass dieser Aufwand stark abnimmt, sobald eine gewisse sprachliche Basis die Szenarien etabliert wurde. Es wird zunehmend einfacher, Szenarien für neue oder geänderte Anforderungen zu formulieren, und der ergänzend zu schreibende Testcode wird immer geringer.
Dem Aufwand gegenüber steht der langfristige Nutzen, den ich abschließend zusammenfassen möchte.
Vorteile von Behat-Tests für die Zusammenarbeit und Ergebnisse im Projekt
Behat-basierte Tests sind für uns ein wertvoller Baustein, um die Qualität in den von uns entwickelten Anwendungen und Projekten zu verbessern.
Sie liegen in einer Form vor, die ohne größere Schwierigkeiten auch von den Projektbeteiligten der fachlichen Seite verstanden und nachvollzogen werden kann. Unsere Auftraggeber können so das korrekte Verständnis der Anforderungen besser beurteilen.
Gleichzeitig bekommen sie ein besseres Verständnis vom Umfang der Tests. Das wiederum kann dabei helfen, in QS- und Abnahmephasen die Aufmerksamkeit auf die Dinge zu lenken, die eventuell nicht oder nur aufwendig automatisiert getestet werden können. Durch die automatisierte Ausführung wird die Qualitätssicherung langfristig von repetitiven, manuellen Arbeiten entlastet.
Ziel: Gemeinsame Diskussion und Verständnis
Diese Zusammenarbeit war durch Reviews und Kommentare auf der Plattform GitHub möglich, die schon in unserem beschrieben ist. Alle Projektbeteiligten konnten so mit einer gemeinsamen Sprache unmittelbar am tatsächlichen Testcode arbeiten. Wir sind überzeugt, dass das insgesamt zur Verbesserung der Kommunikation sowie einem besseren und detaillierteren Verständnis der Anforderungen auf beiden Seiten beiträgt.
Behat-Tests als lebendige Spezifikation
Die einmal erarbeiteten Ergebnisse der Spezifikation bleiben langfristig erhalten. Und zwar nicht als tote Dokumentation“, sondern als lebendige Beschreibung der Anforderungen, die bei jeder Änderung am System überprüft und ggf. angepasst werden kann.
Im besten Fall sind die Ergebnisse sogar übertragbar, falls die Software einmal vollständig neu oder in einer anderen Programmiersprache implementiert werden müsste: Gherkin an sich ist nicht an eine bestimmte Sprache gebunden. Die Testszenarien könnten daher zumindest prinzipiell auf eine neue Codebasis übertragen werden, sofern nicht auch die Anforderungen grundsätzlich geändert werden.