The monthly dose for BDD addicts…  In May stories by Marko Anastasov, Dave Farley, Andrew Knight, John Ferguson Smart & Joe Wright …

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

Dear BDD Addicts,

May was pretty busy for me. There happened many things to me (I did courses, coaching, conference talks, worked on the structure of the Formulation book with Seb Rose), so it is not that easy to find a main theme. But maybe there was something: defining a ubiquitous language. I stumbled across this topic at many places. We use a natural language to describe the requirements. And there are misunderstandings as we know. But the concept that is probably the hardest to understand is that we do not need to define a global meaning of the things we say, but one that helps us in our specific project context (this is what domain driven design calls the bounded context). And on the other way around, we cannot use all the definitions we have learned in other contexts blindly, but carefully listen to the business.

Do you have a good story for that? Write a blog post and share the link with me (bddaddict@specsolutions.eu), so that I can share it with others. Because we also need to listen to other practitioners to improve ourselves.

Here are some of those practitioners I was listening to this month…

Source: wikipedia

[BDD] Executable specifications in the responsibility of the delivery team

I saw Dave Farley’s talk at Craft Conf Budapest last year. Dave’s name might be known to you from the book “Continuous Delivery” that he wrote together with Jez Humble. When you hear Continuous Delivery (CD), probably you first think about build servers, deployment scripts and fast feedback. But the way of ensuring functional quality is also a very important bit. This is the topic he was talking about at the conference and also in the follow-up interview at InfoQ.

Automated Acceptance Testing Supports Continuous Delivery(Dave Farley, @davefarley77)

[Test Automation] BDD for cleaner tests

In one of the past issues (damn, I can find it now which one), I have shared a post that was describing what benefits BDD-style testing can provide, even if you don’t have deep collaboration. I can’t repeat it enough times, how important it is to practice collaboration and requirement discovery. In spite of this fact it is good to have a look at what impact BDD makes for test automation. Andy Knight shared his thoughts about that.

Why choose BDD over other test frameworks? (Andrew Knight, @AutomationPanda)

[BDD] Tool-driven teams

Process driven is good, tool-driven is bad — you would think. But why not think rather about why tool-driven teams operate like they do and how they could introduce BDD more on the process level? Joe Wright summarized this thoughts on this.

Making BDD more than tooling (Joe Wright, @joe_jag)

[Learn:Cucumber/Rails] BDD patterns for Rails apps

One of the key challenges of applying BDD on a concrete technology is to find those detail patterns and practices that connect the overall picture with the concrete tooling. Marko Anastasov made a short summary on how to apply BDD on the Rails platform and the tool-chain around it.

How to build rock-solid Ruby on Rails apps with BDD (Marko Anastasov, @markoa)

[BDD] All those lengthy given steps…

Preparing the context for demonstrating or verifying the application behaviour is one of the hardest bits when it comes to the formulation of the scenarios and the automation of them. We definitely don’t want to write down all the preconditions in all detail, because that would make the scenario unreadable, not even mentioning the maintenance issues. John Ferguson Smart summarizes the different approaches and a good solution for this problem.

How not to prepare test data in JBehave and Cucumber (John Ferguson Smart, @wakaleo)