Dear BDD Addicts,

Summer is on but this year it is going to be a little bit different probably.

I have made use of the lockdown to get more practice with online BDD courses and to move our home office into a new location (a new room within the house). New room, a few new pieces of furniture and a couple of new ideas distilled from the experience of the last five years. Among others, we realized that we needed a recreation area, much more space to be able to store random stuff and that we want to have an office where the floors are free of cables. And we did it. If I see our first room as a prototype or MVP (we intentionally tried to avoid buying furniture before seeing what we really need), this was like a software project that got one iteration closer to the customers’ real need (and also because the move took twice as long as we expected). So let’s keep listening to our customers and try to figure out what they need which is not necessarily what they want… Here are the BDD related articles that I have found most interesting in these months.

Keep reading, here comes the dose…

---

[BDD] Definition of Done brings focus

I can still remember my Scrum training: Definition of Done (DoD) was discussed right on the first day. It sounded clear: we need a checklist to make sure we haven’t forgotten anything. But when we started to apply it in practice, DoD quickly became a list in a template that we copy-pasted to every project without too much care. We never looked at the DoD during the Sprint because it contained only the boring known stuff, like don’t forget to check-in your code and update the documentation.

But Definition of Done is more than that! It is a part of the contract between the team and the product owner. But the contract only makes sense if both sides are able to understand it! And this way we have already arrived at BDD (Specification by Example) and the post by Kalle Mäkelä.

Human-friendly specifications are the key to better software (Kalle Mäkelä, LinkedIn:kallemakela)

---

[BDD] Gherkin challenges with style

Many words have been told about good Gherkin writing principles. Principles are good but applying them to concrete situations might be challenging sometimes. Gojko Adzic proposed a set of such challenges on the specflow.org website. Every week a new challenge is given. The answers are born the community, so feel free to submit your own solution! Are you up for the challenge?

Given-When-Then With Style – The Challenge (Gojko Adzic, @gojkoadzic)

---

---

[BDD] BDD living documentation with Cukedoctor

Spending your time to discuss requirements and automate them as BDD scenarios is a good investment as they provide you with living documentation. But the real value of a living documentation shows up only if you can make it accessible for all stakeholders. Cukedoctor is an open-source tool that can help you with that. Have a look at the detailed documentation and give it a try.

Cukedoctor Documentation (Rafael Pestano & the cukedoctor contributors)

---

[Example] Security-as-code: How to use Gherkin to specify API security expectations

The majority of the BDD scenarios we write describe the system from the end-user’s perspective. While this is absolutely fine, we have to note that BDD is not only good for describing the expectations of the end-user, but generally it complies with the needs of any stakeholder. In the case of a public REST API our stakeholders might include other developers as well who will access our API, but also the personnel who is responsible for security. Randy Gingeleski published a sample project where these aspects are specified and verified. Take a look at their examples and see if they are also applicable to your context. (The feature files can be found in the features/security folder.)

BDD security testing example for Java (Randy Gingeleski, GitHub:@gingeleski)

---

---

[SpecFlow] Processing references from Data Tables

SpecFlow has got a few nice helper functions to process Data Tables. If you haven’t used CreateSet and CompareToSet, it is definitely recommended to have a look at them (in the SpecFlow documentation here). These helper functions solve the most common cases but in the case of building up a more complex data set, you might need to extend them. The post by Jonathan George is presenting such an extension. It comes with full source code and ready-to-use NuGet package.

Using complex objects in BDD Scenarios with SpecFlow (Jonathan George, @jon_george1)

---

[Test Automation] Clarity vs duplications in tests

I stumbled across Arlo Belshee’s article when I was doing some research for the Formulation book. It is a bit old, but still very true and shows through a simple, but concrete example how we should focus on test readability and clarity and not only blindly fight against code duplication.

WET: When DRY Doesn’t Apply (Arlo Belshee, @arlobelshee)

---