TDD does have few challenges, which may affect both the beginner as well as seasoned folks.
- A TDD implementation may be assumption-driven to a certain extent, which may lead to inhibitions like how the current code bit would fit in the bigger picture.
- Trying to specify accurate intent of each unit-test may also be taxing, not only in terms of naming the test, but also in understanding the correct reason for its failure.
- Figuring out scope of testing may also not be straight forward, leading to questions like - where to start, what to test and how much to test?
The objective of TDD is cleaner implementation, but where it falls short is in connecting the "cleaner implementation" with the bigger picture (user-story) that the client would expect to see. Taking a little approach detour, and beginning by writing behavioral scenarios (based on the user-story) first, followed by TDD, the gap between a user-story and its TDDed code implementation can be effectively bridged. This is called Behavior Driven Development (BDD), an approach which supplements the TDD approach.
A BDD Workflow can be elaborated as below -
1. Pick a User-Story
2. Specify a Scenario for the User-Story
3. Run the Scenario and watch it fail
a) Specify behavior of the component of the system, in the form of an example
b) Run the example and watch it fail
c) Implement minimum functionality (using TDD) to make the example pass
4. Run the scenario, and if it fails, continue with 3(a)
5. Write another Scenario
With behavioral tests, there is much more clarity on from where to begin, how much to test and reason for a test failure. BDD is still TDD as it follows test-first programming principle, supports red-green-refactor cycle and based on micro-incremental design.
In a nutshell - - BDD creates more harmony between the user story and the Test-Driven Development. - The user stories practices represent analysis and specification in agile projects and TDD represents software design. - Using BDD, developers are able to best consider the interface from the perspective of the consumer of the service rather than as the producer. - BDD aims to bridge the gap between the differing views of computer systems held by Business users and Technologists.