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