Learn what Business-Driven Development (BDD) is, how it works in a DevOps process, and how to use it with popular Scala development and testing tools.

This article aims to give a brief explanation of what BDD is and how it can be used to fill the information gap between stakeholders and development teams, ensuring everyone (technical or not) is involved in the project’s progress.

The first time I had contact with this approach to software development was a few years ago during a Massive Open Online Course (MOOC) and, I must warn you, I’ve never applied it in production. Nevertheless, I’m fully aware this is not the holy grail and it might not work so well as advertised, but the idea of having everyone on the team (not only developers) collaborating on the development process sounded very romantic to me.

In the past few months, I’ve been working with Scala and I’ve been thinking about what would be the best way to apply BDD using the most popular testing tools in the Scala environment (ScalaTest and Specs2) and the most popular BDD tool: Cucumber. In this article, I will compare these three tools using a very simple example.

What’s BDD?

BDD can be described, in very simplistic terms, as an extension of Test-Driven Development (TDD). The typical TDD cycle, aka Red/Green/Refactor, starts with the development of a failing test. The next step is to write the code to make this test pass and finally, refactor the code in order to improve its readability and maintainability.

In comparison, the BDD cycle is almost identical to the latter, except the first step is replaced by the writing of a specification, rather than the development of a test. This means that this first step can be done by a non-technical person, for instance, a member of the business team or a functional analyst with an understanding of how the system should behave. The best part is that this specification can be used for test automation in the development process.

BDD can also be described as the intersection between Domain-Driven Design (DDD) and TDD. Domain-Driven design is an approach to software development aiming to deal with projects with complex business rules where collaboration between developers and domain experts (typically, this role is assumed by the client) is necessary to set a common language and a domain model that can be translated into very specific and detailed requirements. In BDD, these specific requirements are used to drive the development process in the first step of its cycle.

BDD in Practice

Obviously, BDD can be put into practice without using a specific tool or framework, you just have to get people to collaborate, record that collaboration in some form of specification, and then automate that specification to drive out the implementation. However, there are tools that can help significantly in the automation process, so we don’t have to find a new way to extract values from the requirements to automate tests.

#devops #scala