Wozu automatische Akzeptanztests?
Die Frage stellt sich heutzutage kaum noch, über Sinn, Zweck und Notwendigkeit von automatisierten Akzeptanztests wurde schon erschöpfend diskutiert. Die wichtigsten Argumente im Überblick:
- manuell testen ist zu aufwändig, nicht testen ist unprofessionell und kommt nicht in Frage
- für Continuous Delivery sowieso Voraussetzung
- in Brownfield-Projekten sind automatische Akzeptanztests leichter nachträglich hinzuzufügen als Unit Tests
- sie dienen der Anforderungsanalyse und -dokumentation
- und sind dabei genauer als Prosa
- sie sind Bestandteil der Testpyramide
Damit ist klar, dass nicht die Frage ob, sondern wie im Vordergrund steht.
State of the art
Aktuell werden eine Reihe von Tools verwendet, z.B. Cucumber, SpecFlow, JBehave oder FitNesse. In einem Artikel auf jaxenter wurde von Lean Modeling berichtet.
Wir haben auch Erfahrungen gesammelt mit Office-Dokumente, die speziell formatierte Tabellen enthalten und auf dem CI-Server in ausführbare Testspezifikationen umgewandelt werden konnten. Der Vorteil ist, dass die Fachabteilung mit bekannten Tools wie Word oder LibreOffice Writer arbeiten kann, Bilder, beschreibende Texte usw. leicht einbindbar sind und damit das Dokument den herkömmlichen Spezifikationsdokumenten sehr ähnlich sind. Die Testerstellung war aufwändig, fehlerträchtig, langwierig und mühselig, weil es kein Syntaxhighlighting, keine Codeverwollständigung, keine Refactoringhilfe usw. gibt.
Allen diesen Ansätzen ist gemein, dass die Formulierung in Text dann als Wiederholung in Code auftritt mit den üblichen Problemen: Verletzung des DRY-Prinzips, Schwierigkeiten beim Refactoring, Verlinkung zwischen den Artefakten etc. Der Text ist nicht ausführbar, der Code hingegen ist nur Programmierern verständlich – egal wie viel Mühe sich Frameworks mit Internen DSLs geben. Sie bleiben an die Syntax der Hostsprache gebunden und “können nur Text”.
Außerdem sind Features zur Verwaltung wie Filterung, Sortierung, Fortschrittsverfolgung etc. keine First Class Citizen. Und von der Einbettung/Verlinkung zu weiteren Artefakten wie z.B. Import-/Export-XML-Dateien, Layoutvorlagen oder Beispieldokumente kann man nur träumen (oder sich eigene IDE-Plugins schreiben).
Kurz zusammengefasst: es gibt keine IDE für Anforderungserfassung, -verwaltung und -testausführung.
Domänenspezifische Sprachen
Spezifikationen werden in Zusammenarbeit erstellt. Das ist bei ausführbaren Spezifikationen nicht anders. Notwendige Voraussetzung ist, dass alle Beteiligten dieselbe Sprache sprechen. Damit ist nicht nur die Landessprache gemeint, sondern in diesem Fall vor allem Begriffe und Notationen aus der Domäne. Keinesfalls ist aber eine Programmiersprache gemeint. Die oben genannten Ansätze haben aber alle gemein, dass sie zur Ausführung eine Interne DSL einer General Purpose Language (GPL) benutzen. Diese gibt die Konkrete Syntax vor, die auf die Fachabteilung eher abschreckend wird.
Besser ist es, sich von der GPL zu lösen und eine Sprache speziell für diese Domäne zu verwenden – die Domänenspezifische Sprache. In dieser erfolgt die Programmierung in der Notation, mit der die Fachabteilung vertraut ist. Die Zusammenarbeit ist viel einfacher, insbesondere wenn die DSL nicht nur Text, sondern auch formale Grafiken und die Einbindung erläuternder Bilder und von Beispieldokumenten erlaubt.
Vorteile
Ein großer Vorteil ist, dass die Anforderungen lesbar wie (Prosa-)Text sind , aber auch direkt ausführbar wie (Unit-) Tests in der IDE. Breakpoints und Stacktraces arbeiten genau so, wie man es von der GPL-Programmierung her kennt.
Die Notation muss in der DSL nicht zwangsläufig aus (unformatiertem) Text bestehen. Es sind auch weitere Darstellungsformen möglich: das (OOSE-)Use Case Formular, die SOPHIST-Form, oder eine Tabelle mit den beiden Spalten “Aktion” und “Erwartete Systemreaktion”.
Falls gewünscht, kann man auch mehrere Editoren/Darstellungsformen für denselben Test erstellen: Übersicht/Details, mit/ohne Metadaten wie Autor, Version, Erfassungsdatum, Stabilität usw. Je nach Projektphase, Aufgabe oder Informationsanfrage wählt man die am besten passende Sicht auf den Datenbestand.
Auch abgeleitete Darstellungen sind leicht integrierbar, z.B. kann ein Use Case Diagramm aus den Use Cases generiert werden.
Wer möchte, kann die Sprachen so gestalten, dass die Verwaltung der Anforderungen genauso First Class Citizen werden wie deren Erfassung. Mittels Annotationen und Metadaten sind Sortier- und Filteroperationen möglich.
Es besteht auch die Möglichkeit, gleich noch den (Java-)Produktivcode in der Language Workbench zu schreiben, wenn sie die verwendete GPL unterstützt. Dann ist es leicht, harte Links zwischen Anforderungen und Code setzen. Die Nachverfolgbarkeit der Umsetzung von Anforderungen im Code und der Verweis vom Code auf die Anforderungen ist somit gegeben. In MPS ist dies mit Java und wenigen Language Extensions möglich, das ebenfalls MPS-basierte mbeddr ermöglicht die C-Programmierung.