TDD or BDD… What’s your flavor?
Very recently I was asked to give a series of talks about Unit Testing at work, I must say, I’m not an expert by any means, but throughout my career I have done my share of unit testing, so I guess I’ve learned a thing or two.
While researching for these talks, just to be sure that what I was telling was true, I realized Jasmine is a BDD framework, which makes total sense if you’ve worked with it. So, it made me think, not many people know about development methodologies, this definitively had to be one of the subjects I had to talk about.
Let’s start with the basics, what is a software development methodology?
A methodology per se, is a series of previously established steps to follow in order to achieve a goal or objective, then, a software development methodology is about the steps and techniques to approach the development of a software.
There are several methodologies you could follow when developing a project, currently the most known would be TDD Test-Driven Development.
What is Test-Driven Development?
Simply said, it’s development based on tests, it’s a cycle where a test is built to fail and, according to the results, a function is built to make the test succeed, then a new test is made to fail and the cycle starts again.
Write test -> Fail -> Code -> Success -> repeat until everything is done.
Another methodology, a bit similar, is BDD Behavior-Driven Development, development based on an expected behavior, clear? Not so much? Let’s see.
What is Behavior-Driven Development?
BDD is an approach where the objective is to fulfill a group of acceptance criteria. Here, the tests are built to verify predefined, discussed and accepted criteria the project must comply.
It’s a cycle where a test is built to fail and, according to the results, code is built to make the test succeed, then a new test is made to fail and the cycle starts ag… uh?
WAIT! isn’t that the same as TDD? well… kind of(?)
It’s all about what you want to test.
You see, the main difference between these two approaches is the test goal and how we get to know what that goal is, and that’s it, just that, seriously.
The criteria on which the BDD tests need to be based, should reflect the expected functionality from the end users perspective, so we need a whole team, this means Stakeholders, Project Manager, Technical Leader, Business Analyst, Designers, Developers, QA team, yes, all the team.
In practice this could translate to:
- As an end user I would like to see an app that calculates different basic operations for two given values.
- The app should display buttons for numbers from 0-9; and each button should trigger the display of given number when clicked.
- The app should display buttons for operators +,-,*,/; and each button should trigger the display of given operator when clicked.
- The app should comply to the next UX guidelines: …
- And so on…
Sure, you very much could define acceptance criteria without the Dev and QA team, but from my perspective, I’d never underestimate the insight a Jr Dev might give, the best ideas can come from places you least expect them to come, remember ratatouille?
On the other side TDD doesn’t necessarily need a whole team, one Dev could be more than enough, why? because with TDD the goal is to test isolated pieces of code, and make sure they work as they’re supposed to work. Putting this into code it would mean:
- I need a function that should sum two values.
- I need a function that should multiply by two values.
- And so on…
Are they mutually exclusive?
Absolutely not, you could test that your whole code actually fulfills the user story acceptance criteria, while at the same time, test that the different sections of the code fulfill their own different purposes.
So, Which one is better?
Good question, these two approaches while similar in steps, are intended for different objectives. So, as one of my favorite mentors always says “It depends”, BDD could be considered as the evolution of TDD, I personally like to see it as a complement for TDD.
Where BDD could take more time to start while the acceptance criteria are defined and for the same reason it becomes more complicated, TDD is more a hands on approach, so it’s generally faster and easier when done well.
TDD helps you to test your code but, because it is isolated code, you might not get to test the interaction with the rest of the code, whereas with BDD you can be sure your whole code delivers what the client is expecting to get, because you’re testing the different parts of your code interacting with each other.
Personally, I like to use both, BDD for the whole user story, TDD to define my functions and classes, is that too weird?
So, tell me, TDD or BDD, what’s your flavor?
Happy coding everyone! see you next time and remember, life is what passes while you’re debugging and trying to solve the bug you can’t find.
