Behaviour Driven Development (BDD) mit SpecFlow DNCGN 2019

Behaviour Driven Development (BDD) mit SpecFlow DNCGN 2019

Automatisierte Tests sind unser Sicherheitsnetz als Entwickler. Wie kann ich aber mit dem Fachbereich zusammenarbeiten und die Spezifikation festhalten, sodass diese ebenfalls automatisiert getestet werden kann? Behaviour Driven Development gibt darauf eine Antwort. Und mit SpecFlow lässt sich das in .NET-Code automatisieren. So können wir Business-Anforderungen in eine lebendige Dokumentation überführen und gleichzeitig deren Erfüllung nachweisen. Wir durchlaufen die Reise von der initialen Story über die Entdeckung der Akzeptanzkriterien bis zur Formulierung der Spezifikation und Automatisierung der Validierung (mit Live-Coding bzw. Code-Beispielen).

Beispiele unter:
https://github.com/skorzinetzki/dncgn-2019-bdd-pizza/tree/dncgn-2019
https://github.com/skorzinetzki/dncgn-2019-specflow-selenium/tree/dncgn-2019

D99c2a3a8f27cffbcd0a390286aba109?s=128

Steve Korzinetzki

May 10, 2019
Tweet

Transcript

  1. 3.

    Hände hoch! ▪ Wer kennt BDD? ▪ Wer kennt die

    „Given When Then“ Schablone? ▪ Wer kennt die drei Phasen von BDD?
  2. 6.

    BDD ist die fehlende Verknüpfung 6 „Bridging the communication gap“

    (Gojko Adzic) Business / Stakeholder Dev-Team
  3. 7.

    BDD Definition „BDD practitioners explore, discover, define, then drive out

    the desired behaviour of software using conversation, concrete examples, and automated tests.“ 7 From Cucumber for Java Book by Seb Rose, Matt Wynne and Aslak Hellesøy 1. Phase: Discovery 2. Phase: Formulation 3. Phase: Automation
  4. 11.

    Testing Iceberg ▪ die Fachabteilung ist betroffen (BDD) ▪ technisch

    (TDD, …) 11 Wer hat ein Interesse daran, die Tests zu lesen?
  5. 12.

    Die drei Phasen von BDD Discovery Formulation Automation 12 Gemeinsames

    Gespräch zwischen Fachabteilung, Entwickler, Tester, … Entwickeln von gemeinsamem Verständnis und allgemeingültiger Sprache. Das gemeinsame Gespräch wird aufgenommen / verschriftlicht Es wird also die Spezifikation definiert. Die Beispiele werden in Szenarien abgeleitet. Die Szenarien werden mit dem dazugehörigen Test- und Produktiv-Code untermauert. Es entsteht eine lebendige Dokumentation.
  6. 13.

    Develop BDD Workflow 13 #1 Pick a User Story #2

    Requirement Workshop #3 Formulate #4 Review #5 Automate #7 Supplementary tests #6 Implement (TDD) #8 Release From Discovery by Gaspar Nagy and Seb Rose
  7. 15.

    Impact Mapping Story Mapping Code Examples Acceptance Criteria User Stories

    Epics User Activities Reise agiler Anforderungen 15 From Impact Maps and Story Maps by Christian Hassa https://de.slideshare.net/chassa/2014-0618srdimpact-mapsstorymapsen Example Mapping Erinnerung daran, eine Konversation zu haben Warum? Outcomes Wie? Spezifikation Deliverables Impacts Goals früher später
  8. 16.

    Develop BDD Workflow 16 #1 Pick a User Story #2

    Requirement Workshop #3 Formulate #4 Review #5 Automate #7 Supplementary tests #6 Implement (TDD) #8 Release From Discovery by Gaspar Nagy and Seb Rose Example Mapping Discovery
  9. 17.

    Example Mapping 17 From Introducing Example Mapping by Matt Wynne

    https://cucumber.io/blog/2015/12/08/example-mapping-introduction Gemeinsames Verständnis
  10. 22.

    Develop BDD Workflow 22 #1 Pick a User Story #2

    Requirement Workshop #3 Formulate #4 Review #5 Automate #7 Supplementary tests #6 Implement (TDD) #8 Release From Discovery by Gaspar Nagy and Seb Rose
  11. 23.

    SpecFlow Feature File Beispiel 23 Feature: pizza-change-delivery-address As a customer

    I want to change the delivery address after ordering a pizza when not picked up yet so I can recover from delivering to the wrong address Scenario: Pizza waiting for pickup, changing delivery address should be accepted Given "Peter" orders some pizza to "home" address And the pizza is waiting for pickup When the customer wants to change the delivery address to "work" Then the system should accept the change Scenario: Pizza already picked up, changing delivery address should be denied Given "Tim" orders some pizza to "home" address And the pizza is picked up by the driver When the customer wants to change the delivery address to "work" Then the system should deny the change with message "Already picked up"
  12. 24.

    Develop BDD Workflow 24 #1 Pick a User Story #2

    Requirement Workshop #3 Formulate #4 Review #5 Automate #7 Supplementary tests #6 Implement (TDD) #8 Release From Discovery by Gaspar Nagy and Seb Rose
  13. 26.

    Fazit ▪ Problem? Signifikanter Anteil an Fehlern durch falsch verstandene

    Anforderungen – Anforderungen der Fachabteilung verstehen und deren Umsetzung nachweisen ▪ Wann? Wenn die Fachabteilung ein Interesse am Ergebnis hat. ▪ Vorteile • Verkürzte Feedbackschleife, Fehler frühzeitig entdecken • Allgemeingültige Sprache • Lebendige Dokumentation ▪ Herausforderungen • Bereitschaft des Fachbereichs • Automatisierung erfolgt methodenübergreifend