BDD: TDD done right

Test Driven Development(TDD) is a widely spread software development process that has proven successful in practice and is being adopted by more and more companies around the world. However, there are some dangers when applying TDD blindly. This blog post explores some common misconceptions about TDD and shows how they can be avoided using Behaviour Driven Development (BDD).

What is TDD?

Test Driven Development can be summarized as a procedure which follows these simple steps:


image taken from http://code.tutsplus.com/tutorials/beginning-test-driven-development-in-python--net-30137

  • Write an automated test case that fails for the new feature you want to implement
  • Run all tests and see that the new one fails
  • Write the code for the new feature
  • Run the tests, ensuring the new feature works correctly and that no other features were broken
  • Refactor – meet all coding standards and conventions that your team adopts and ensure the new functionality is in the right logical place in the project. Run the tests again to ensure nothing was broken during refactoring.
  • Repeat process with a new feature

This very short development cycle allows the developer to concentrate on just one specific problem and the completion of the cycle signifies that the new feature works correctly. Furthermore, the automated testing facility ensures that if changes impact this particular feature in an incorrect manner, then the test suite will immediately notify the developer of the problem. One more advantage of TDD is that developers are asked to think in more detail about the eventual use of the feature, which lets them get a clearer picture of how it is supposed to act and where it might fail.
TDD has been reported to decrease the number of defects and to limit code complexity. This is due to the fact that features are implemented just in time, which decreases the chances of overbuilding the system by implementing unnecessary features.

Sounds good. So what’s wrong?

Nothing! At least not in the technical sense. However, there is much which can be done to improve the human element of the system.
One of the main problems of the methodology is the usage of the term ‘test’. This automatically puts the developer in a validation mindset – and this is not the purpose of TDD. As instead, Test Driven Development should be a process to guide the design and not to overcomplicate things. This is where Behaviour Driven Development comes in.
In an attempt to escape the validation mindset it redefines the vocabulary to make developers view the process as a tool for specification. Now, instead of ‘tests’, BDD teams concentrate on behaviour and instead of ‘assertions’, they write method names like ShouldEqualFive() or ShouldRaiseNullException() which makes it easier to understand.
This simplification of the language makes the tests(it’s hard to get away from the word completely) not only a specification for the project, but also a sort of documentation and a validation tool that anyone(not only developers) can understand. This ease of use creates a ‘ubiquitous’ language for everyone in the development process – developers, stakeholders, managers and domain experts with specialist knowledge. The ease of communication that follows is very beneficial as it helps ensure that the team is building the right software – since the stakeholders understand it, they can just tell the devs that the specification is wrong. And what is even better is that it is often possible to get a sense of what the next most important part of the project is, thus reducing the time spent working on features that are less important and likely to change.

Syntax

To describe the different behaviours, BDD uses a story template and a scenario template. The story template has the following syntax:
As a [X]
I want [Y]
so that [Z]
where X is the role requesting the feature Y which brings the benefit Z to X. Each story also has a title, so that it can be referred to by name.
Now these stories are associated with scenarios which go as follows:
Given some initial context (the givens),
When an event occurs,
then ensure some outcomes.
And I don’t even need to disambiguate what this syntax means. This simplicity allows everyone associated with the project to join in the design and specification phase and the scenarios that end up being written later become the tests that the developers use to create the product.

BDD viewed as an Expert System?

I am totally new to Behaviour Driven Development(hence the question mark in the heading), but all of these contexts,events and outcomes bring me back to an AI course I took some time ago. More specifically, we(it was a 2-person project, so I’ll stick with the we) were asked to implement a fitness instructor expert system. An expert system is a computer system that emulates the decision-making ability of a human expert. Now, we knew close to nothing about the world of fitness instruction and yet we were tasked to create a product that given some input would come up with an appropriate exercise schedule. The key to the project was to go around real-life fitness experts and ask them about their viewpoints and based on their answers, to create a set of logical rules that describe their knowledge. For example, if a person wanted to lose weight, then he needed to do more cardio, but if he had back problems then he was advised to avoid certain exercises. This set of rules highly resembled the scenarios described above.
Now, we knew what we needed to build, but we were lacking the building blocks. The next part of the project was to create an ontology. According to Wikipedia, an ontology formally represents knowledge as a set of concepts within a domain, using a shared vocabulary to denote the types, properties and interrelationships of those concepts. Sound familiar? Let me give you an extract from the Wikipedia article on OOP: An object contains encapsulated data and procedures grouped together to represent an entity. The ‘object interface’, how the object can be interacted with, is also defined. An object-oriented program is described by the interaction of these objects. As you can see, these definitions are really similar. The last part required us to just write up the rules in a formal system, which would interpret them and give us the output.
This is why I believe that the development of an expert system can be compared to BDD. But an expert system is crafted in such a way as to act as if it is a real human expert in the field. And since BDD mimics the mindset of the stakeholders, then the final product will be an expert in the field of the requirements of the stakeholders. Thus, the project is more likely to behave according to their desires.

Conclusion

Behaviour Driven Development is, in its core, the same as Test Driven Development. However, it differs in the way that people think about the process. BDD lets people abstract to a more general level and allows input from all involved parties. This makes it an outside-in specification and ensures that the final product meets most of the requirements of the stakeholders, thus increasing the quality of the project.

References and Further Reading

Introducing BDD – the original post by Dan North
Comparative Study of Test Driven Development with Traditional Techniques
Interview with Dan North on Behavior-Driven Development
From Test-Driven Development to Behavior-Driven Development