Dear BDD Addicts,

COVID came to Europe two years ago and it has changed many things in the software industry. And now, after two years, the Ukrainian crisis again changes many things.

I did many SpecFlow courses with Ukrainian attendees and also have a few friends there from my conference visits in Kyiv. Although an individual cannot do too much but I feel that it is my responsibility to stand by them and raise my voice against the meaningless violence affecting innocent civilians including children. We have decided with Seb Rose to donate all income we receive from BDD Books in March and April to help Ukrainian refugees. If you want to help, go to https://bddbooks.com and buy the books on LeanPub, Amazon or Audible.

BDD helps people to better understand each other and make a better software. I hope this will also help a little bit to rebuild what has been destroyed.

So, let’s see the dose for this month.

---

[BDD] Interview with Aslak Hellesøy

Aslak Hellesøy is the founder of Cucumber and his efforts are invaluable in making BDD as it is today. As I wrote in one of the BDD Books, by making the Gherkin format a de-facto standard specification language instead of keeping it a private component of Cucumber enabled to elevate BDD to a general concept and methodology.

In this interview you can read or listen how he sees the history and future of BDD and Cucumber. (The interview transcript was made based on a podcast recording.)

Cucumber Founder Aslak Hellesøy on TDD and BDD (Aslak Hellesøy, @aslak_hellesoy)

---

[Agile Testing] Plan your tests based on risks

One of the common problems I see is that teams try to apply a few selected test types and expect to get a “good coverage” based on them. Maybe you can get a good “line coverage”, but the majority of the problems is not at the code lines. The code lines just do what you asked them to do. But did you ask them to do the right thing?

When we say “coverage”, it should be more related to what we wanted or what we are afraid of. To be able to achieve this, we need to be more aware of what these are.

In this post Lisa Crispin is sharing her experience with a technique called “risk storming”. She is also talking about how to introduce such a method at a company and provides a concrete example as well of how the end result might look like.

Quick risk strategizing (Lisa Crispin, @lisacrispin)

---

---

[Agile] Focus on doing the right things

At discussions about BDD vs TDD, people usually say that TDD is about doing the things right and BDD is about doing the right things. While this is obviously a slightly oversimplified statement, but probably most of us have seen projects failing, even though the best teams were on it and they really did good quality code. Just not for the right problem.

This is caused by focusing on efficiency only and not effectiveness, as Johanna Rothman is explaining in her post through a simple example.

Focus on Effectiveness, Not Efficiency (Johanna Rothman, @johannarothman)

---

[Testing] Don’t Repeat Yourself Unless It’s Worth It

The ones who follow the BDD Addict newsletter know that the Test Automation Pyramid is one of my favorite topic. The pyramid is not a model, as many teams think, but more like a thinking tool to build your own test strategy.

I liked Matt Bailey’s article because he is describing the valuable use of the pyramid in a very simple and easy-to-read form. The section title “Don’t Repeat Yourself Unless It’s Worth It” is actually taken from the article itself, so you can see that he also addresses the problem of overlapping tests in the pyramid.

Balancing the Test Automation Pyramid (Matt Bailey, linkedin:mattblankbailey)

---

---

[SpecFlow] Make your step definitions free of input data pattern handling

One of the keys to success for BDD is to keep the specification – the scenarios in the feature files – consistent. A consistent language or notation can help the readability and understandability of the scenarios, and it also makes the maintenance much easier.

Besides the consistency of the language, you might also want to use some patterns for expressing input data. Maybe your application handles currencies and you always include them in the same form: currency code and value, e.g. “EUR 123.4”. In some other cases you need to use some markers or placeholders in the text input. I often use this for asserting error messages. Instead of including the final message to the scenario, I only include a key to them and keep the final text in a resource file. To make it visible that the text is just a (readable) key and not the exact message, I use a specific format, for example dashes instead of spaces: “this-is-a-message-key”. Of course these keys have to be resolved in the automation code based on the current resource file, but thanks to the parameter conversions you don’t have to do it in every step definition where you want to assert for a message.

In his blog, Gerben van Adrichem provides an example for using such conversions in SpecFlow.

Automatic parsing of parameters in SpecFlow (Gerben van Adrichem)