SDWest: Behavior Driven Development
This morning I'm learning about Behavior Driven Development (BDD) from Dave Astels. At its core, BDD is just Test Driven Development (TDD) with different syntax.
TDD relies on unit testing frameworks, and everything you do references testing: Your tests execute within a TestCase. You Assert that conditions are/not true. You VerifyValue class member values. Everything conspires to make you very focused on the state of the object under test. This is one reason why wars often break out regarding whether private methods should be unit tested - private methods are part of the object's state, so from some points of view it makes just as much sense to unit test them as it does to unit test the public methods.
BDD changes the focus from testing state to specifying behavior. Your tests execute within a Context. You state that behavior should/not be true. The environment helps you focus on the behavior that should result from a specific context rather than the state that should hold in a specific case.
Like I said, pretty much just TDD with different syntax. Dave believes, however, that the different syntax induces a different frame of mind. I've only been doing BDD for two hours, but I would have to agree. The language you speak affects and to some extent restricts the thoughts you can think. This is true for spoken languages, it is true for programming languages, and this morning I'm learning that it's true for design languages as well.
One potential downside is that BDD's supporting framework rSpec is only available for Ruby. (Which, I'm learning, is a very fun language!) Dave says there are Java and .Net implementations in the works, however. Hopefully we won't have to wait too long!
Comments
- Anonymous
March 14, 2006
You are exactly right about BDD helping you to think about specification better. I personally believe by forcing myself to follow a strict test naming convention based on the principles and ideas around BDD, it helps me specify and think better about what I’m trying to achieve when doing TDD… or should I say BDD.
I follow the following convention [desired-result][coordinator][conditions] as a pattern to specify the behavior.
e.g. Create a Stack and verify that IsEmpty is true.
- Desired Result: IsEmpty is true
- Coordinator: when // use when, should, etc.
- Conditions: Stack first created
[IsEmptyIsTrueWhenStackCreated]
One of the posters on the TDD list conned this pattern and after I tried out quite a few different approaches, I’ve found the above pattern to work best for me.
I've also created a VS2005 TDD code snippet library that helps me write tests quickly and enforces this test naming rule. You can find it at http://www.codeproject.com/dotnet/UnitTestCodeSnips.asp - Anonymous
March 14, 2006
The comment has been removed - Anonymous
March 14, 2006
Visual Studio Team System has some magic goo that allows unit testing of non-public members as well. Not that I'm advocating doing so! I'm a strong believer that non-public members should be ignored: either they have some public behavior you can verify, or it doesn't matter what they do. - Anonymous
March 14, 2006
Maruis: I use a similar naming convention for my TDD test methods. There's a tool - I forget its name - that generates documentation out of such well-named test methods: it figures out where to add spaces and punctuation and such to make well-formed sentences and so generate specifications out of your test methods. Cool stuff! - Anonymous
March 14, 2006
- In paragraph 4 you say "I've only been doing TDD for..." I think you mean BDD.
2) I think agileDox might be the tool you are thinking about (agiledox.sourceforge.net)
- Anonymous
March 14, 2006
Dave: I fixed the typo; thanks for catching it! agileDox does indeed sound like the tool I was thinking of; thanks for the link. - Anonymous
March 14, 2006
Pretty much sums up my experience in Dave's morning tutorial:
http://edgibbs.com/2006/03/14/behavior-driven-development/
I really enjoyed the session, and the more I play with it the more I like Ruby.