BDD - I think I'm finally getting some understanding
Nick Hines from Thoughtworks led a really good session on BDD at ALT.NET UK. The session clarified a lot of things for me, though as always after a bit of thought I am left with plenty more questions so I thought a blog entry was in order.
What Is BDD
My initial experience with BDD was Dave Astels doing a videocast about it. Better TDD and focussing on design were the name of the game. This made sense but when I started looking into it more I got a bit lost. The documentation seems to focus on the influence of DDD and the use of interaction testing. This confused me a bit as unless you practice need-driven development its questionable whether you are using interaction design as a domain design technique. I was also confused as to how BDD fit in with DDD, other than both sharing the idea of a ubiquitous language.
Anyway the discussion clarified the fact that its fair to view BDD as better TDD and it has little to do with need-driven development (though I guess you could use them together). It also doesn't specify that you must be using interaction testing.
Where to use BDD
We also came to the conclusion that these tests were quite high level, more influenced by users (user story acceptance tests) or a business analyst. I'm thus not clear that they would influence the domain design other than at a shallow level as your users are normally not your domain experts. This is probably what Greg Young means when he talks about BDD being used to for a shared language which may be distinct from the ubiquitous language.
Practically this probably means writing these tests against high level domain entities or your application/service layer. The discussion did cover whether you then take the BDD tests into the domain and indeed right down to hidden implementation details. I'm still not clear on this but if we are using BDD tests as specifications then starting out with detailed high level specifications isn't a bad idea, it gives us a good way of specifying acceptance criteria.
More Questions
The question is then how detailed to make these high level BDD tests. They have to be quite detailed and comprehensive if they are acceptance tests but if you make them too comprehensive then you are going to end up testing the same things at multiple levels, initially with a high level BDD test then with more detailed "unit" tests.
This seems attractive to me though, Jimmy Bogard has a great post about how he tried to make sure his BDD tests are somewhat immume to refactoring (changing implementation).
Other Links
Ray Houston is one of many people blogging about learning BDD, including this really interesting post.
@Colin - I have the same questions to which level of detail do you take the BDD tests. Saying that BDD is TDD done well makes me think that the methodology does go down to the unit test level. Our group is currently experimenting with trying to find to right balance. I'm currently under the impression that it's ok that you will end up testing the same things at different levels (which could be completely wrong and I might change my mind next week). We are defining high level behaviors, then behaviors of behaviors, etc., until the implementation is complete. At each level that we're defining behavior, we're trying our best not to worry about the details of the implementation (at that particular level), but at the lowest level you don't have a choice. I would be uncomfortable saying that we don't need the low level unit tests, so we're sticking with them for now but writing them in a different way so the read like specifications.
ReplyDeleteYeah I get you.
ReplyDeleteFirst off I'm not using BDD on our project yet so feel free to ignore all of this.
My worry would be that TDD naturally leads you to tests that are quite coupled to implementation. How coupled depends on how far you go with unit testing, but if you go to a very granular levels (including encapsulated/internal classes) then any change is going to cause you to rewrite tests (even if no behavior changes)
These tests are useful but they don't necessarily give you good examples of usage (particularly of the public API) and this is probably why I liked Jimmy Bogards post because I really feel our system is missing the tests that he describes.
But yeah I guess you could use the same approach at lower levels, but then I would wonder whether the style of syntax that BDD is all about (http://dannorth.net/whats-in-a-story) necessarily works so well when you get down to implementaiton details?
Oh and I agree about needing the lower level tests as well as the high level ones, its just something that I hadn't realized when I first looked at BDD.
This comment has been removed by the author.
ReplyDeleteYou might want to check out this
ReplyDeletepost by Elizabeth Keogh. Might help.
Thanks, yeah I noticed that article was up and have put in a discussion comment about it. Its left me with more confusion though :)
ReplyDelete