What’s the Difference Between TDD and BDD?
In TDD (Test Driven Development), the test is written to check the implementation of functionality, but as the code evolves, tests can give false results. BDD (Behavior Driven Development) is also a test-first approach, but differs by testing the actual behavior of the system from the end users perspective.
This article makes close analysis of TDD and BDD to see how they match or differ in their prime characteristics.
Test Design
In both TDD and BDD approaches, tests are written upfront before the actual code is written. Writing tests first helps predict the course of the development, which will ultimately prevent any cases being missed from the code or functionality. Prevention of bugs will be the main aim of these approaches, and these tests will also act as concrete documentation of what is planned to be achieved in terms of test coverage.
Test Method
Within these approaches, the tests are ‘programmed’. In order to write these tests, strong coding skills are required. So by programming these tests, they can be ‘automated’ for later use.
Workflow
Workflow is as simple as the illustration below shows. You think, discuss and come up with ideas. These ideas will be converted into tests, with the first test being expected to fail. Code is written later that will enable the test to pass. Once the test has passed, the code will be refactored further to eventually arrive at the best design. This newly refactored code will continue to be put under test until the design has been finalized.
Behavior vs. Test
“What are you testing for?” is a great question to ask. Are you testing to figure out the behavior of the application? Or are you testing the actual implementation? This is the biggest point of discussion when you talk about BDD and TDD. In BDD, you are looking for the behavior, for example, what will happen to this system under a certain condition. But in TDD you have a test for a method which will assert some conditions, but as the system evolves these tests may give you false results.
To simplify this further, it can be written:
In TDD, I don’t care much about the output. The only thing needed is to carry out the test in a particular way.
But in BDD, I don’t mind how you come up with the output, only that the output has to be correct under the GIVEN condition.
Communication and feedback
BDD has the edge over TDD in this area. Since behavior in BDD is written in simple, descriptive English, your clients will be able to understand the tests and more quickly send their feedback. These more open lines of communication allow you to better incorporate their feedback to improve the tests and design of the software further. In TDD, only skillful programmers can understand the test, which of course, limits communication with the wider audience but this method will deliver code of a higher quality.
Again, but in simpler words:
In BDD you will come across a better specification since communication between the software developer and product owner is fast and easy.
TDD may lack the ability to specify the exact behavior, but you achieve higher quality with software code.
Writing Failing Tests vs. Writing Failing Feature Tests
As discussed, both approaches start with writing a failing test and then picking it up from there. In BDD, a test is written that can satisfy both the developer and customer, but in TDD you write a test that will only satisfy a developer and the code they write. As can be seen below, BDD works over TDD, which will make TDD implementation a better approach. So you can never say that BDD and TDD are entirely two different things.
Summary
Although we say BDD is a better approach, we must not forget that BDD has actually evolved from TDD, as a way to eliminate the shortfalls of TDD. So there is absolutely no harm in implementing both approaches – one to support the quality of the code the developer writes, and the other to support the behavior of the system defined by the product owner.