Test-Driven Vs Behaviour-Driven Development

"Vision Artwork" by arztsamui/Freedigitalphotos.net

Your choice of software development methodology typically defines your team’s goals and the principles you operate by to achieve them. Test-driven and Behaviour-driven developments are two categories of specification/development that every technical team (Developers, designers, testers and analysts) should be aware of.

Test-Driven Development (TDD)

Test-driven development defines a series of steps that are to be followed strictly before any development can take place. As the name implies, it places emphasis on the need to test every unit of code (even before the code is written) before full development can begin. You start by testing for a functionality (which fails), then you write just enough code to ensure the test passes. You then test the code and make corrections where necessary until the test is passed. Once the test is passed, you refactor the code (clean it up by removing redundancies, etc) and move on to the next piece of code.

It can also be regarded as an opportunity to think through requirements before writing code.

Although it seems pretty straightforward, the lack of specification on what to build can cause problems. Problems of what to test for, how much to test, and how to find error-prone cases often come up, prompting Dan North to enhance the process and come up with what is now known as Behaviour-Driven Development.

Behaviour-Driven Development (BDD)

Behaviour-Driven Development stemmed from the challenges of using test-driven development. Dan North, the developer of BDD, noticed how vague TDD was and devised a clearer method of working towards the desired outcome.

BDD places significant emphasis on the need to balance technical elements with business interests through the use of specific software tools. While TDD is devoid of the specifics needed to understand what makes a test fail or succeed, BDD digs deep into every aspect of the requirement/system behaviour.

With Behaviour-driven development, product requirements are expressed as examples, which are used to clarify and describe requirements. Examples may also be referred to as scenarios. These scenarios are more explicit since they help stakeholders identify their needs, prioritize them and validate the solution after implementation.

BDD is an agile technique that brings developers, analysts and testers together through the use of scenarios. Scenarios that are written in a behaviour-driven development format allow business analysts to specify events, conditions, and actions which can later serve as acceptance test criteria. The BDD format facilitates the documentation of examples/scenarios and is as follows:

• GIVEN <a context>
• WHEN <an event>
• THEN <an outcome> 

There are lots of software applications that accept scenarios written in BDD format and convert them into automated tests allowing for faster system delivery. BDD requires every user story to have an explicit title and a narrative that explains who benefits from the system feature, what behaviour they are after and what value they expect to get out of it. Different scenarios of system usage are described with specific details on the pre-conditions, how the scenario should start and what the expected outcome is.

While Test-driven development is developer-focused, Behaviour-driven development is user-focused.

With BDD, you implement only those requirements that contribute directly to achieving business outcomes using a notation that is understandable by domain users, testers and developers to improve communication and the general outcome of the project.

Useful Links

See more on Behaviour-Driven Development from Dan North.