The monthly dose for BDD addicts…  In March stories by Paul Grizzaffi, Chris Kessel, Liz Keogh, Thomas Pierrain & Gil Zilberfeld …

Subscribe to the monthly newsletter at http://bddaddict.com so that you never miss it! (Did you get the February issue?)

Dear BDD Addicts,

March was pretty busy, but there was a topic that I stumbled across several times this month: how to get business involved in BDD. Practicing the discovery part of BDD is challenging, especially if you have to change an existing established company culture. There is no easy way and I can tell you that forcing people to work differently will not help either. You have to find the way to make them aware of the benefits and find the right techniques. This months a few of the articles I am sharing are dealing with this topic. I hope they will help. Have you read another good one? Please send me the link to bddaddict@specsolutions.eu, so that I can share it with others.

But now… let’s see the monthly dose.

[BDD] E = m * c2  – specifying calculation formulas

Many BDD demonstrations start with the calculator example: add two numbers. Although it is pretty uncommon that you have to implement a calculator using BDD, sometimes we need to specify, automate and implement applications that have to work according to a mathematical formula. (Or at least this is a typical example that people want to use to challenge BDD –commonly the real problems cannot be simply modeled with a mathematical formula… but this is another topic.) How to test such a formula? How many examples do we need? Liz Keogh is here with the answer on

Stack Overflow: How to specify an equation with BDD (answer by Liz Keogh, @lunivore)

[BDD] The automation is not the hard part

As we have also stated in the discovery book, the key BDD practices are the discovery of requirement details, the formulation of these into BDD scenarios and automating these to be able to verify the implementation result. Believe it or not, but for many teams the biggest challenge of all these is the first one: talking to each other, working together to have a shared understanding of the details. Paul Grizzaffi’s post is also about this topic: the importance of shared understanding.

Behavior-Driven Development and Automation: Establishing Order(Paul Grizzaffi, @pgrizzaffi)

[BDD] Event Storming

Collaborating to understand the requirement details is important, but not easy. Fortunately there are techniques that help you to get up to speed. Many teams use example mapping, which is a simple technique and works in most of the cases. Another interesting technique that can help a lot to clarify domain details is event storming. The technique was described by Alberto Brandolini and is getting more and more popular, especially in connection with Domain Driven Design (DDD). Even storming is a generic domain discovery technique, which can also be used with BDD. Thomas Pierrain shared a short summary about it.

Event storming: Domain distillation under steroids (Thomas Pierrain, @tpierrain)

[TDD] It’s TDD’s fault!

Test-driven development (TDD) is a well-known technique for guiding development with (unit) tests. It is well-known, but this does not mean that it is well-practiced usually: many teams struggle with introducing TDD. In many cases the problems are caused by simple mistakes. Gil Zilberfeld shared eight typical TDD anti-patters to help. The link goes to the first one (TDD without refactoring), but in the article header you can also find the others.

Unit tests anti-patterns (Gil Zilberfeld, @gil_zilberfeld)

I am happy to speak at Coders Who Test — a half-day conference about testing in a Continuous Delivery framework.

 15th May, 2018, Gothenburg (Sweden)

The conference will feature a series of talks for a whole afternoon. Come and discover how adopting best practices and better tooling can get your Continuous Delivery pipelines flowing like never before!

To get ready for the conference and make the most out of it, you can also choose to attend additional workshops. More details about the different ticket options on the conf website.

[Learn:SpecFlow] Parallel MsTest

SpecFlow v2 introduced in-appdomain (in-process) parallel execution that had been initially available with xUnit and NUnit, later with SpecFlow+ Runner. Finally this also works with MsTest as well and the article by Chris Kessel describes step-by-step, how to use SpecFlow with parallel MsTest execution.

In-assembly Parallel “IAP” Test Execution using MsTest V2 and Specflow (Chris Kessel, Chris’ CodeProject Profile)