Behavior-Driven Design

With Agile, testing is part of every iteration, testing processes are highly automated,  developers test their own code and QA team members continuously improve testability & tools.

Software quality is the result of good processes & tools

Behavior Driven Design is a full-stack agile methodology that supports such endeavors. In practice however, using tools that implement Behavior Driven Design workflows are intimidating to learn.

To start with Agile however, I find it far more crucial to get first the words right by describing software behavior using the Domain Specific Language (DSL) that comes with BDD. Most of the problems that delivery teams are facing are communication problems.
BDD aims to help communication by simplifying the language we use to describe scenarios in which the software will be used: Given some context, When some event occurs, Then I expect some outcome :

  • The given part describes the state of the system before you begin the behavior you’re specifying in this scenario. You can think of it as the pre-conditions to the test.
  • The when section is that behavior that you’re specifying.
  • Finally the then section describes the changes you expect due to the specified behavior (post-conditions).

BDD enables closer collaboration with users, bankers, developers, testers, programmers, operators, project managers or any other FInTech project stakeholder.

Another interesting use of BDD is to facilitate integration and communication between different distributed systems as described in Ben Mabey’s post Using cucumber to integrate distributed systems and test messaging. His work opens doors with respect to testing strategies of asynchronous systems using Swift, Fix, MQ messaging systems or even distributed ledgers.

So, do not get only the process right, but also the words!

Behavior-Driven Design

One thought on “Behavior-Driven Design

  1. I want to make a strong case here to use the declarative style of writing scenarios.
    Lately, I wrote Given-When-Then test scenarios in imperative style, which needed to be executed manually by QA professionals. They contained many granular steps. The focus of these tests was more on ‘how’ to execute them. I was dead wrong 😦

    Instead, with the declarative style of writing, the goal of the scenario gets clear. The description is less verbose and the focus is on ‘what’ to test. It’s far more efficient, less time-consuming and much more fun for those who have to execute such scenarios manually. Many thanks to the team who gave me that great feedback 🙂


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s