These are two different techniques. The key to each of them is about the mindset and context of what you want to achieve.
BDD is a “test-driven feature”
Basically, it’s a test-first driven development, where the main focus is ensuring the expected final behavior, and therefore the result of the software logic that you want to have at the end.
In BDD the main focus is the behavior of your domain logic that doesn’t exist yet. It is, from an abstract point of view, about the whole functionality and domain requirements.
TDD is about the rhythm
- Specify what you want.
- Make it work.
- Make it better.
TDD is not just about the already known “red-green-refactor” mentality, but mostly about the workflow that helps you understand the constant design decisions you are doing every time for every logic you are designing.
TDD is about constant feedback about your decisions.
In the context of OOP (to make the examples clearer), there are always tons of different ways to design your class:
- What’s the name of this method’s class?
- What are the dependencies or collaborators for this class?
- How will this class behave when I use this other class inside it?
- What’s the expected outcome of this method when I give these arguments?
- etc, etc…
We do these questions (and many more) every time, and we do give them an answer as well, but usually without any rational thinking or feedback about it. We just do what we think is “the best” at that particular time focusing on making something work, but is it enough to make it work?
The constant feedback loop
Testing is not just a great tool because it gives you some safety-net so you can refactor with confidence, but also because it helps design a better system. How is that? Because before going for any solution, it makes you think about the decisions that you need to do. You are challenging yourself to understand the arguments of your decisions, and why A and not B is a better solution in a particular context.
BDD and TDD aren’t mutually exclusive, in fact, they can and should coexist. It depends mostly on the context of what you want to build and test.
BDD is about Test-First feature development. The goal is not how but what. The feedback loop is long because you will get “green” feedback once the feature is implemented and working as expected.
TDD is also another Test-First driven but, unlike BDD, it is about a shorter and quicker feedback loop.
- First, you specify what you want. You think about the design of your class or method. Its name or signature. Its dependencies. But all of this by baby steps, one at a time.
- Second, you make that little thing work in the simplest possible way.
- Finally, you make it better. Because software is hard and complicated enough to make it right on the first try, so refactoring is a must to keep a system healthy. At this point, with a “green running test”, you can refactor and improve your logic safely.
The above is basically TDD, right, but… what’s so special about it? The constant feedback loop and design decisions that you need to make before you are actually writing the solution. This is the power of TDD.
Why so small steps in TDD?
Theoretically you “must” write little steps for every iteration, but why? It’s all about the feedback loop. This is up to you, your expectations, and your experience with testing.
