I’ve often read/heard the following kind of critique comparing TDD (Test-Driven Development) and BDD (Behavior-Driven Development):
BDD is great, but unlike TDD, it can’t catch little things like obj.length vs. obj.length()
Such assertions tell me that we need to improve how we teach BDD. BDD is TDD. Many argue BDD is simply TDD “done right”. So why the new name? Because Test-Driven Development, thanks to its misleading name, tends to place inordinate emphasis on testing over design, prompting immediate resistance from developers and project managers alike.
Alright Mr. SmartyPants, how do we ensure our BDD covers “little things” such as obj.length versus obj.length()? I’m glad you asked! Suppose we are working with the following Story and Scenario:
Feature: Count my friends
In order to track my popularity
As a social networker
I want to be given a sum of all my friends
Scenario: Add friends
Given Tom, Jerry and Tweety are my friends
When I add Sylvester and Sylvester Jr. to my friends
Then I should have 5 friends
And the following Cucumber steps for JavaScript (purposefully not DRY, for the sake of demonstration):
Given(/(.*) are my friends/, function(s)
{
me = new Person();
var friends = s.split(/,\s?|\s?and\s?/);
for (var i in friends)
{
me.friends.push(new Person({ name: friends[i] }));
}
}
When(/I add (.*) to my friends/, function(s)
{
var friends = s.split(/,\s?|\s?and\s?/);
for (var i in friends)
{
me.friends.push(new Person({ name: friends[i] }));
}
}
Then, depending on which is needed, one can easily test obj.length:
Then(/I should have (.*) friends/, function(n)
{
assertEqual(n, me.friends.length);
}
Or obj.length():
Then(/I should have (.*) friends/, function(n)
{
assertEqual(n, me.friends.length());
}
Voila! Now your BDD is covering your length/length() dilemma, and you didn’t have to “switch back” to a “test-driven” mindset.