Hinweis: Die aktuelle German Testing Day Konferenz finden Sie hier!

Konferenzprogramm

Konferenzprogramm 2020

Track: Methods & Tools

Nach Tracks filtern
Alle ausklappen
  • Mittwoch
    02.09.
12:05 - 12:40
Mi 1.3
Spock und AsciiDoc - vom Test zur Spezifikation und zurück
Spock und AsciiDoc - vom Test zur Spezifikation und zurück

Spock ist ein BDD Testframework für Webanwendungen. Der Product-Owner beschreibt das Verhalten einer Applikation und der Entwickler überprüft es über einen automatischen Test.

Wäre es nicht cool, wenn daraus ein verständliches Dokument erzeugt würde?
Kein Problem! Wir generieren einen Testreport mit Screenshots in AsciiDoc und fügen weitere erklärende Texte hinzu um eine les- und ausführbare Spezifikation zu erhalten.

Aber sollte die Spezifikation nicht am Anfang stehen?
Also zurück auf Start und die Tools rückwärts angewandt!

Zielpublikum: Entwickler, Product-Owner, Tester
Vorraussetzungen: Grundwissen über BDD
Schwierigkeitsgrad: Advanced


Extended Abstract:
Spock ist ein Testframework für Webanwendungen, mit dem man unter anderem den Behavior Driven Development Ansatz, kurz BDD, verfolgen kann. Der Product-Owner beschreibt das Verhalten einer Applikation und der Entwickler überprüft es über einen automatischen Test.

Dem Entwickler reicht die Ausgabe 'PASSED' oder 'FAILED', denn er kennt ja den Code seiner Tests. Wäre es nicht cool, wenn auch der Product-Owner ein verständliches Dokument bekäme?

Kein Problem! Wir generieren über ein Template einfach einen Test-Report in AsciiDoc und fügen weitere erklärende Texte hinzu um eine les- und ausführbare Spezifikation zu erhalten. Screenshots aller wichtigen Schritte bereichern die Spezifikation weiter.

Sollte aber die Spezifikation nicht am Anfang stehen? Und warum Spezifikation, wenn wir agil sein wollen?

Richtig! Stellen wir also eine iterative Feature-Beschreibung an den Anfang und verfeinern diese mit automatischen Tests um am Ende eine gut lesbare und verifizierbare Spezifikation des Verhaltens unseres Systems zu erhalten!

Die Vorteile liegen auf der Hand - die Vorgehensweise verbessert die Kommunikation zwischen Product-Owner und Entwicklern und am Ende bekommen wir ein Dokument, welches Ihre wertvolle Software korrekt und überprüfbar beschreibt.

Christian Fischer works as a Software Engineering Coach at DB Systel and loves TDD, Extreme Programming and Craft Beer.
Ralf is a Software Engineering Advocat at DB Systel during the day and after sunset he loves everything whit bits and bytes. The last few years of his career, he focused on the documentation of software systems with arc42 and the Docs-as-Code approach.

Christian Fischer, Ralf Müller
Christian Fischer, Ralf Müller
Vortrag: Mi 1.3

Vortrag Teilen

Zurück