• Part 1 – Ubiquitous Language

• Part 2 – Implementing Scenarios and Step Definitions in Specflow

• Part 3 – Benefits of using BDD Programming Methodology

In a series of articles, we will use illustrative examples to explore the various aspects of Behaviour Driven Development (BDD)

Dan North came up with the idea of BDD as a programming methodology that makes it easier for all stakeholders to communicate effectively with each other.

BDD, as the name suggests, focusses on the ‘behaviour’ of the system. In order to do so, it uses what is called ‘ubiquitous’ language’, which is designed to enable better communication by providing a common technical vocabulary and grammar that is understood by all participants. This way, business analysts, testers, developers are more likely to be all on the same page, sharing a common understanding, when requirements are being discussed.

Ubiquitous language was originally proposed by Eric Evans in his 2003 book titled Domain Driven Design. Evans argued that requirements written in day to day language could be used in the implementation and not just in the business domain. He further reasoned that each stakeholder group had their own jargon which is open to a lot of misinterpretation by another stakeholder group. Eric Evans called this the “linguistic divide” in the book and showed how with the use of ubiquitous language which will be understood by all stakeholders, these challenges can be overcome.

In the course of these articles, we will be exploring various aspects of BDD, particularly:

• The Ubiquitous Language in BDD
• Executable Criteria using Ubiquitous language and how they are used
• how we can use the results from the Executable Criteria to improve the quality of the application.

In this first article, we will discuss BDD in general terms and then look at the significance of using Ubiquitous Language. We will use a simple ‘Coding Club’ case study for illustration and this will be described as we progress through the basic BDD concepts.

Contrast with TDD

Although Test Driven Development (TDD) has brought us new methods of improving code-quality, there are a few problems with it. Firstly, there is visibility. Even though the tests serve to define the way that the parts of the application work, the other stakeholders, such as the business analyst, tester, or the customer, have no way of observing or participating, and hence these tests do not become part of the User Acceptance-Testing (UAT) or even the initial requirements-gathering. Oftentimes, the test and the implementation are based on the interpretation of the requirement by the programmer who is writing the code. If and when a requirement is misunderstood, it often has to be implemented all over again with a cost in time and resources, as well as requiring more meetings between all the stakeholders involved.

The key difference between TDD and BDD is that, while TDD focusses on the functionality of the system, BDD is focused on its behaviour. TDD involves writing a test for a particular functionality and making sure the test passes after the code for the functionality is written. For example, say we have a Coding Club system where we want to be able to add and remove members. The TDD methodology would be focused on writing tests for the various methods, implementing the methods and then making sure that the tests pass. These tests are often based entirely on the developer’s interpretation of the various aspects of the Coding System and at times the interpretation by the development team may not be the same as what the customer wants.

With BDD, there is frequent communication amongst the stakeholders and everyone is kept in the loop. This helps to clarify misinterpretation and/or misunderstandings early on in development before it gets to the stage of having to abandon or refactor a great deal of work. The use of ubiquitous language enables all stakeholders, whether they are technical or non-technical to communicate easily and effectively.

Using Ubiquitous Language

Let us explore this by using an example. We will look at how it is easy to misunderstand a requirement that is gathered using the techniques of traditional requirements’ analysis. Then we will look at the BDD equivalent of that requirement and see how those problems and misunderstanding can be eliminated.

Let’s imagine that there is a requirement to have a ‘Coding Club’ system, which allows an administrator of the system to add and remove members, and hold information about the members such as their names, coding interests and professions.

The administrator would certainly need to maintain the membership list. Using traditional requirements’-gathering methodology, one of the requirements in the specification could be:

Enable the administrator of the Coding Club system to add or remove a member.

This requirement can be interpreted a number of different ways by the business analyst, tester, client and the developer. Some of the key hurdles could be:

• The requirement does not have enough detail. For example, it does not specify what mandatory information an administrator needs to be able to create a user account. What about the contact details? Does the client prefer that, in the contact details, either the email address or phone number, or both, ought to be mandatory?
• With Test Driven Development, the developer will write the test just before writing the code for the functionality, based on the developer’s understanding of the requirement. The client has no way of checking that this understanding is correct and, in even this level of detail, misunderstandings can derail development: The developer’s understanding could be that all registration fields should be mandatory whereas the client may not want certain fields to be mandatory.
• When the application is passed on to the testing team, their interpretation of the requirements may be different again and will be reflected in their test scripts. The result of this would be that a lot of time and resource will be wasted here while the developers and testers try to agree on what the requirements mean. The client may not be aware of misunderstandings regarding the requirements till after the development work is completed, the internal testing has been done and the User Acceptance Testing is in progress.
• In TDD, the phrase “All the tests have passed” will only make sense to the developer, and this information alone will not help the client to check that the functionality meets the requirements of the application.

Now let us take a look at how BDD will help resolve these communication problems. As stated earlier, the key benefit of using ubiquitous language is that, from the beginning, all the stakeholders will share an understanding of the requirements. Let’s look at the same examples of how some these scripts would be written for the Coding Club system.

Dan North talks about the concept of a user story. He defines a user story as – “It has to be a description of a requirement and its business benefit, and a set of criteria by which we all agree that it is “done”.” In other words, it is the specification for the requirements, but using ubiquitous language will be written in a way where it will make sense to everyone right from the beginning.

A user story comprises of a title, a narrative and acceptance criteria (referred to as scenarios). Let’s illustrate this using the Coding Club example where the requirement is to enable an administrator to be able to add a new member to the system.

• Title: Add new member to Coding Club
• Narrative:
• As an administrator of the Coding Club system
• I want to be able to add a new member to the system
• so the person can get membership of the Coding Club

The template recommended by Dan North is:

• Given some initial context (the givens),
• When an event occurs,
• then ensure some outcomes.

Based on that template, some scenarios for our Coding Club system could be:

Acceptance Criteria

• Scenario 1: New member’s name is not blank
• Given I have the new member’s information
• And the new member’s name is not blank
• Then I should be able to proceed to the next field

• Scenario 2: New member’s profession is not blank
• Given I have the new member’s information
• And the new member’s profession is not blank
• Then I should be able to proceed to the next field

• Scenario 3: New member’s coding interest is not blank
• Given I have the new member’s information
• And an option is selected from the Coding Interest dropdown
• Then I should be able to proceed to the next field

• Scenario 4: All of new member’s mandatory information is available
• Given I have the new member’s information
• And all the mandatory fields have been filled in
• Then the Create User button should be active

• Scenario 5: Create User button is active
• Given all the mandatory fields have been filled in
• And the Create User button is active
• When I click the button
• Then the new member’s profile should be saved in the system

By using this language from the very beginning, communication becomes easier, and a lot of questions about the requirements are cleared up before the development work begins, thereby saving a lot of time and resource over the long term.

The key benefits for the Coding Club project would be:

• Questions about which fields need to be mandatory can be asked at the requirements-gathering stage.
• The customer may not initially be entirely clear about what they want, so there is an opportunity the customer to discuss with the business analyst, developers and testers about where clarification is likely to be necessary.
• There is a good level of granularity in the requirements because there are various scenarios to specify how the system needs to behave. This minimises ambiguity in the requirements. Every field has a separate scenario.
• These scenarios become the User Acceptance Criteria, so the goals are crystal clear to all stakeholders from the beginning to the end of the development cycle.
• Because the acceptance criteria are executable, the programmer will need to write code which executes the criteria successfully. This ensures that the code meets the criteria that were agreed with the stakeholders at the beginning. This idea will be explored in more detail in the next article.

Summary

The purpose of this article was to show how BDD enables us to allow greater participation in the development process by using ubiquitous language. We discussed how, by using ubiquitous language, we can clarify the requirements from the very beginning, so that there are no ambiguities which could mislead the development work. Furthermore, the customer has a chance to clarify the detail of their requirements for the system, so that the developers know what they need to develop and the testers know exactly what needs to be tested. The scenarios are then used as the acceptance criteria by the customer while they carry out user acceptance-testing, which again saves a lot of time.

How do developers use these scenarios written in ubiquitous language? How do they ensure these tests are successful before passing it on to the testing team? We will answer these questions in the next article where we will look more closely the Executable criteria can be used for testing.

References

• Introducing BDD by Dan North
• What’s in a Story by Dan North