Cucumber ohne BDD - hat es einen Nutzen?

Cucumber ist in für die meisten Menschen eng mit Behaviour Driven Development (BDD) verbunden. Im Kern ist Cucumber allerdings ein Test Runner, welcher die Gherkin Schreibweise mit Code verbindet und das entwickelte System testet. Dementsprechend kann es auch von Teams genutzt werden, die kein BDD einsetzen. In diesem Beitrag sprechen wir über diese Konstellation und ihre Daseinsberechtigung. Zunächst gehen wir auf mögliche Gründe für diese Herangehensweise ein und schauen uns eine kleine Warnung an. Danach sprechen wir über mögliche Vor- und Nachteile sowie einige häufige Probleme, um abschließend zu einem Fazit zu gelangen.

Warum setzten Teams Cucumber ohne BDD ein?

Das kann verschiedene Gründe haben. Ich werde diejenigen aufzählen, die ich selbst in Projekten erlebt habe. Dabei werde ich weder auf deren Vor- noch Nachteile eingehen und nur darstellen, was die Idee dahinter ist.

1. Die Team versuchte, Fachexperten von BDD zu überzeugen. Das gelang nicht, Cucumber wurde allerdings als Tool etabliert.
2. Ein Projekt nutzte Cucumber, da es das Xray Jira Plugin zufrieden stellt. Das Team musste Testaufwände für eventuelle Audits dokumentieren. Das System bot (auf den ersten Blick) zwei Möglichkeiten dafür: manuelle und Cucumber Tests. Im richtigen Umfeld könnte das sogar eine Chance sein, die Zusammenarbeit im Team in eine bessere Richtung zu lenken und BDD zu verproben.
3. Andere Teams nutzten Cucumber für spezifische Szenarien in einem von BDD inspirierten Ansatz. Hier wollen Tester und Fachexperten nur einen geringen Anteil möglicher Fälle händisch testen, der Rest sollte automatisiert werden – mit Reports, die sie verstehen können.

Es gibt weit mehr Gründe als diese, da bin ich sicher. Kennst du einen weiteren? Dann lass uns doch gerne einen Kommentar da und wir lernen gemeinsam.

Cucumber ohne BDD kann ein Notbehelf sein

Cucumber hat das Ziel eine lesbare Datei für Entwickler bereitzustellen? Das ist ein Zeichen für ungelöste Probleme im Projekt. Die wirklichen Vorteile von Frameworks wie Cucumber kommen, wenn Fachexperten zumindest mit den Beispielen interagieren. Beispielsweise als Grundlage für eine Diskussion oder als Unterstützung bei der Erarbeitung von Verbesserungen.

Ist das nicht der Fall? Dann sollten wir gründlich über die Struktur unserer Tests nachdenken. Verstecken wir unsauberes Testing? Ja? Dann verschwenden wir vermutlich Zeit mit dem Schreiben komplexen Glue Codes anstatt simplere (bspw. JUnit) Tests einzusetzen. Und solche Probleme treten selten alleine auf. In vielen Fällen sind andere Aspekte unseres Projekts ebenfalls in Schieflage, beispielsweise die Architektur.

Ich arbeitete mit einem Team, das diesen Ansatz verfolgte. Sie hatten eine schlechte Architektur und dadurch eine schlechte Testbarkeit. Das Problem wurde durch Cucumber Tests auf der API oder Component Integration Ebene „gelöst“. Dadurch wurden selbst kleinste Tests zur anstrengenden Aufgabe. Große Bestandteile der Anwendung mussten für jeden einzelnen Test aufgebaut werden. Beispielsweise die Datenbank. Und das für Szenarien, die mit guter Architektur ein simpler Unit Test gewesen wären. Schlussendlich wurden diese Tests aus zwei Gründen geschrieben: Um lesbare Tests zu erstellen und das Testmanagementsystem zufrieden zu stellen. Letzteres sprengt den Rahmen dieses Blogbeitrags.

Beispiele, die für jeden, der kein Softwareentwickler ist, unverständlich sind, waren das Ergebnis. Aber: Mit etwas Arbeit konnten wir zumindest dieses Problem lösen. Außerdem konnten wir in einigen Teilen der Anwendung eine besser testbare Architektur etablieren. Und die Änderungen zeigten sich deutlich. Die neuen Beispiele konnten für die Kommunikation mit Fachexperten genutzt werden und die Anwendung wurde verständlicher und wartbarer. All das wurde durch den Einsatz des gesamten Teams erreicht.

Aber genug für diese „kleine“ Warnung, kommen wir zurück zum Inhalt.

Vorteile, wenn Entwickler .feature-Dateien schreiben.

Richtig angegangen, sind .feature-Dateien in einer verständlichen Sprache geschrieben. Damit meine ich Deutsch, Englisch, Spanisch und andere Sprachen, nicht Java, Typescript oder Python. Die Ergebnisse der Testausführung führen zu einer aktuellen, validierten und – am wichtigsten – verständlichen Dokumentation. Für Entwickler, Tester und Fachexperten gleichermaßen. Und hoffentlich deckt es auch die Aspekte mit dem höchsten Risiko und Wert ab.

Hilft bei der Definition und Wartung von Features

Angenommen wir haben einen Bug in unseren produktiven Umgebungen. Wir können mit unseren Fachexperten die Ergebnisse der Testausführungen analysieren und sehen, was falsch definiert ist oder fehlt. Hierbei sollte der Schwerpunkt auf den Reports, nicht auf den reinen Beispielen liegen. Sie liefern eine bessere Übersicht. Gemeinsam finden wir das Problem einfacher und schneller. Und noch besser: In vielen Fällen können fehlende Beispiele einfach hinzugefügt und mit geringem Mehraufwand automatisiert werden. Und natürlich gilt dasselbe auch für die Entwicklung neuer oder die Erweiterung bestehender Features. Genießen wir regelmäßig diese Vorteile, kann Cucumber ohne BDD den Aufwand wert sein.

Nochmals: wenn wir unsere Beispiele Fachexperten vorlesen, können einfachere Verfahren sinnvoll sein. Das Projekt, das ich zuvor erwähnte, war in einer solchen Situation. Das war anstrengend, da wir nicht nur die Beispiele übersetzen, sondern auch zusätzliche Aufwände bei der Automatisierung stemmen mussten.

Ein Ansatz für spezifische Szenarios

Kürzlich sah ich ein Team, dass .feature-Dateien nur in spezifischen Situationen nutzte. Und diese waren selten aber sehr wichtig für die Fachexperten. Und diese wussten verständliche und automatisierte Beispiele hierfür zu schätzen. Haben Sie eine vollständige und lebende Dokumentation ihrer Software? Auf keinen Fall. Aber sie haben ein Problem gefunden, bei dem beide Seiten verständliche Tests haben möchten. Und die Lösung funktioniert für sie. In anderen Situationen hat das Team gemerkt, dass die aufgewendete Zeit nicht sinnvoll investiert ist, wenn sie die Vorteile nicht nutzen.

Um es klarzustellen: Viele dieser Szenarien können simpler angegangen werden. Beispielsweise mit .csv gestützten parametrisierten Tests. Das spart den Aufwand für die Integration von Cucumber. Aber die Wahl ist kein Problem, wenn es für das Team funktioniert, ich weise lediglich darauf hin, dass es sinnvoll ist, alle Möglichkeiten anzuschauen.

Das Team hatte sogar noch einen weiteren Vorteil von diesem Ansatz: Ihr Testmanagement-Tool unterstützt .feature-Dateien standardmäßig und bietet dadurch einen Weg Audits zu absolvieren. Dementsprechend war es ein Gewinn, die Situation war aber sehr spezifisch.

Mögliche Schattenseiten von Cucumber ohne BDD

Die erwähnten möglichen Vorteile scheinen attraktiv. Aber sie kommen mit Kosten und es gilt, diese zu rechtfertigen. Unser Ziel ist die Lieferung hochqualitativer Software mit Mehrwert für das Unternehmen. Und im vorliegenden Fall lauern Fallen, welche unserer Effizienz schaden können.

Die Sprache der Beispiele wird nicht von Fachexperten genutzt

Entwickler und Fachexperten sprechen verschiedene Sprachen. Erschwerend kommt hinzu, dass sie oft dieselben Worte mit verschiedener Bedeutung verwenden. Um die Vorteile von Cucumber ohne wirkliches BDD zu nutzen, müssen alle Teammitglieder die Beispiele verstehen können. Ohne Übersetzung. Andernfalls wird nur wieder das Muster unnötigen Mehraufwands sichtbar.

Dieses Problem zu fixen ist eher einfach. Besprechen Teams ihre Beispiele, sagen wir in einem Scrum Refinement Meeting, können Sie diese Ungereimtheiten ausbügeln. Die Teams bilden Schritt für Schritt eine gemeinsame Sprache. Das ist auch im sonstigen Projektverlauf von Vorteil.

Beispiele werden sehr technisch

Verwandt zum vorherigen Thema sind rein technisch geschriebene Beispiele. Schauen wir uns dazu ein Beispiel an, das sich an Fällen orientiert, die ich in Projekten erlebt habe:

Das ist in vielerlei Hinsicht problematisch. Als erstes wird ersichtlich, dass das Beispiel nicht aus der Perspektive eines Nutzers geschrieben wurde, da diese in der Regel nicht mit REST-Controllern interagieren. Zudem sind sowohl Request Body als auch Status Code technische Begriffe. Nutzer interessieren sicht nicht dafür und müssen sich auch nicht dafür interessieren. Anstatt das Beispiel weiter zu kritisieren, lasst es uns neu schreiben:

Offensichtlich ist das sowohl ein einfaches Beispiel als auch eine Übertreibung. Aber solche Beispiele sah ich in einem früheren Projekt von mir öfters. Das führt dazu, dass .feature-Dateien nur für Entwickler nützlich sind. Und so treffen wir unser übergreifendes Problem von Cucumber Einsätzen ohne wirklichen Mehrwert wieder.

Problematische Dateinamen

Wie kann eine Datei schlecht benannt sein? Im vorher genannten Team, wurden die .feature-Dateien nach den Tags der Stories unterteilt und benannt. Sie hießen beispielsweise XYZ-1234.feature. Aber warum ist das schlecht? .feature-Dateien sollten, wie der Name suggeriert, Features repräsentieren. Eine User Story ist allerdings kein Feature, sondern in der Regel nur ein Teil davon. Zudem werden Ticketnummern vergessen. Das führt dazu, dass die Dokumentation von Features aufwändig gesucht werden muss.

Angenommen das obige Beispiel sei die Beschreibung unseres Features. Das File sollte entsprechend nicht XYZ-1234.feature heißen, sondern eher document-upload.feature. Wollen wir Stories referenzieren, können wir dafür beispielsweise das Cucumbers tag Feature nutzen.

Ohne die Vorteile zu nutzen, ist Cucubmer ohne BDD einfach zu teuer

In der Realität ist Effizienz ein wichtiges Thema. Wir schreiben nicht zum Spaß Software für Unternehmen, sondern um Mehrwert zu generieren. Meist kann dieser in Kundenzufriedenheit oder Gewinn gemessen werden. Schreiben wir anstelle von simplen JUnit, Jest oder Selenium Tests Cucumber Tests mit einer zusätzlichen Ebene an Komplexität, kostet das zusätzliche Ressourcen. Wir zahlen aber nicht direkt auf die Kundenzufriedenheit ein, wenn wir dadurch keine anderen Hürden reduzieren. Dementsprechend existiert kein Gewinn durch die investierte Zeit und das bereitgestellte Geld.

Zusammenfassung

In einer perfekten Welt arbeiten Fachexperten, Entwicker und Testspezialisten eng zusammen und kommen mit guten Beispielen, die automatisiert werden können, zu einer lebenden und stetig wachsenden Dokumentation. In der Realität ist das nicht immer der Fall. Teams können trotzdem von Beispielen in Gherkin Notation profitieren. Aber hierfür müssen einige Voraussetungen erfüllt sein.

Als Erstes müssen Fachexperten in der Lage sein die Beispiele zu verstehen, da sonst gutes Feedback fehlt. Und sie sollten zusätzliche Vorteile für das Projekt bieten, sei es für spezifische Szenarien, als Diskussionsgrundlage oder in anderer Form. Und abschließend sollten Teams gut evaluieren, ob eine andere Herangehensweise in ihrer Situation besser geeignet ist oder ob sie gerade einfach nur schwerwiegende Probleme übertünchen.

Habe ich etwas vergessen oder hast du eine Frage zu Testansätzen? Dann schreib uns doch gerne einen Kommentar oder kontaktiere mich per E-Mail.