Test-Driven Development and Behavior Driven Development

Behavior Driven Development and Test-Driven Development both follows the test-first approach. In TDD the test is written to check the implementation of functionality, but as the code evolves, tests can give false results. In BDD, testing is conducted to test actual behavior of the system from the end users perspective.

Goal of TDD and BDD 

In both TDD and BDD approaches, tests are written upfront before the actual code is written. Writing tests first helps clear the course of the development, which will ultimately prevent any cases being missed from the implementation or functionality. Prevention of bugs will be the main aim of these approaches.

Test-Driven Development
Consists of following steps :

1. Start by writing a test
2. Run the test and any other tests. At this point, your newly added test should fail. If it doesn’t fail, it might not be testing the right thing and probably a buggy code.
3. Write the code required to pass the test
4. Refactor your code
5. Repeat from 1

Advantages of TDD

• Code is fully tested code upfront. It's painless testing.
• It also forces you to keep it simple.
• Writing the tests first requires you to really consider what do you want from the code
• Reduces time spent on rework
• Less time spent in the debugger
• Tells you whether your last change or refactoring has broken previously working codes
• Allows the design to evolve and adapt to your changing understanding of the problem
• Forces you to write small classes focused on one thing
• Creates SOLID code
• Maintainable, Flexible & Easily Extensible

Behavior Driven Development 

The primary purpose of BDD methodology is to improve communication among the stakeholders of the project so that each feature is correctly understood by all members of the team before development process starts. This helps to identify key scenarios for each story and also to eradicate ambiguities from requirements.

In BDD, Examples are called Scenarios. Scenarios are written in a special format called Gherkin. The scenarios explain how a given feature should behave in different situations with different input parameters. 

Acceptance tests should be written using the standard agile framework of a User story:

“As a [role] I want [feature] so that [benefit]”. Acceptance criteria should be written in terms of scenarios and implemented as classes:
Given [initial context],
when [event occurs],
then [ensure some outcomes].

Advantages of BDD 

• It involves getting stakeholders and delivery team with different perspectives onto the same page and ensuring that all have the same expectations.
• The goal of BDD is a business readable and domain-specific language that allows you to describe a system’s behavior without explaining how that behavior is implemented.
• Scenarios are written in the form of plain text features descriptions with scenarios typically written before anything else and verified by the non-technical stakeholders. No development skills are required for creating scenarios.
• BDD helps to focus on the user’s needs and the system’s expected behavior rather than focusing too much on testing the implementation.

Tools?

Cucumber is a Java framework for BDD, by its support for the particular set of interactions between team members and stakeholders. Cucumber can execute plain-text functional (feature) specifications as automated tests. The language that Cucumber understands is called Gherkin.