In the first workshop they introduced the concept of BDD, and demonstrated the development workflow for building a system based on Gherkin acceptance criteria.
Jonas explained the key concept of “specification by example” and how it can be formalized using Gherkin to build the ubiquitous language amongst all stakeholders in a project. That’s why SpecFlow and Gherkin are actually aiming at specifying the details of a system. Testing of the completed system for compliance is just a by-product. Having the detail specification bound to the actual implementation ensures, however, that it is kept up-to-date throughout the whole application life cycle. It makes detail specifications valuable even after finishing the implementation of a given feature, as they are a business readable description of how a system truly behaves.
After the theoretic introduction, Gaspar did a coding demo, binding and implementing the first Gherkin formulated acceptance criteria of their sample domain. He used the SpecFlow book shop sample (using an MVC2 architecture), where he automated the first Gherkin scenario through the controller. From there, he implemented the necessary logic using TDD, until the scenario turned green. After that, there was an exercise for the audience to bind and then implement the next acceptance criteria for the application.
The second workshop focused on the process of how to harvest useful acceptance criteria and the challenges involved with that.
After a short introduction, the audience got the task to formulate acceptance criteria (scenarios) in Gherkin for a given user story (feature) – using pencil and paper. The groups presented their results and there was a discussion about the challenges people encountered and anti-patterns we found in the results. This exercise made it obvious to everyone, that the key concept to master in BDD is not the tool (e.g. SpecFlow), but understanding the process of distilling and formalizing acceptance criteria in Gherkin.
I particularly liked this part of the workshop, as it not only was an exercise for the individual participants, but also a good demonstration for the challenges in BDD. Even if you are just watching the podcast, the discussion of the results and challenges everyone found is helping a lot to get a better understanding on detail specifications in Gherkin. Also Gaspar’s comment on the technical “TDD perspective” of a developer vs. the “business perspective” on acceptance criteria provides lots of insight.
The second workshop concluded with a summary of challenges and anti-patterns we encountered so far in our experience, and a discussion about how testing fits into BDD. In our projects we mostly automate below the UI, as this is much cheaper to achieve and maintain. It also ensures, that we really can automate all specified acceptance criteria. The main goal of using SpecFlow is not automating through the UI, but having an automated verifiable detail specification. Even if you automate through the UI, it doesn’t spare you additional efforts such as explorative testing.
If you are interested in using SpecFlow, I strongly recommend you watching those two workshops. Skillsmatter has put both of them online as a video podcast:
- Workshop 1: Driving an ASP.NET MVC application outside-in with SpecFlow
- Workshop 2: Advanced Topics of Behavior Driven Development with SpecFlow examples
(Note: podcasts will become available in the next few days)
If you are interested in getting deeper into SpecFlow and need a head start, we can provide similar workshops on-site in the domain of your own project. Contact us at info_at_specflow_dot_org.