It’s about time I’ll wrap up my BDD blog series before I forget what went through my head and before you all loose interest.This time it won’t be a very code intense post, although there will be some. You don’t have to have read my previous posts about my BDD and Yatzy adventures. I will probably refer to them though.

I believe that the biggest shift, if you look at TDD <-> BDD as opposing occurrences, is how you look at your tests. With BDD, or even Acceptance Test Driven Development (ATDD) you have to think about real functionality. Real value, which is going to be added to an application.

You really don’t have to do that when your unit testing a specific class. So, in my opinion TDD can be done unit-test-style or BDD-style. Unit-test-style is more about testing specific classes and their methods while BDD tests one or several classes or methods.

Unit-test-driven code will probably look like this:

public void testGetScore() throws Exception {
	Roll roll = new Roll();
	assertEquals(roll.getScore(), 0));
}

Whereas the BDD equivalent would look more like the code below. It probably wouldn’t have had a separate test for Roll. Instead it would be tested through some other tests. Maybe just like the code below. I snatched this example from from my SectionBehavior-test.

public void testScoreForAPLayerIncludesAllRolls() throws Exception {
	section.addRoll("Player", new Roll(new int[] { 1, 1, 1, 1, 1 }));
	assertThat(section.scoreForPlayer("Player"), is.eq(5));
}

While BDD puts (a lot) more focus on the problem at hand and the tests that should pass for this new functionality to be valid you can easily fall into the trap of creating bigger classes. This happened to me in the Yatzy example. The Game class made all important descisions and grew out of proportions. Really quick too.

Although it took some time before I could figure out what was wrong I finally realized that it wasn’t just one problem. It was a whole bunch. The duplication was hiding classes that wanted to come out. A few instances of Maps and Lists also indicated that fact.

Once again it’s time to stress the fact that refactoring it’s an absolute necessity.

In the Yatzy example it also became quite clear to me that you should probably spend close to a third, maybe even more, of your time doing refactorings. And the other two thirds on tests and implementation.

To sum things up: BDD generates tests that covers bigger areas of functionality thus making the implementation easier to refactor to a certain extent. Because of this you’ll have to be very disciplined and really be on the look out for duplication, hidden classes and be aware of the usual test and code smells.

Advertisements

About Ola Ellnestam

Agile Coach, Systems developer, Agile Practitioner and father of three.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s