Yesterday I was at a dojo at Agical in Stockholm.
The idea of a dojo is to as a group drive out the design of a piece of code using TDD. The goal is to practice TDD outside of real live projects.
We used a method called randori that meant that we worked on the code as a pair, describing to everyone what we did and switching out one of us every now and then. It was a trilling experience to say the least, if only too short! I'm definitely going to go to more of these dojo's :)
When we where done we got into discussing the differences between BDD and TDD. What does it really mean to drive your development based on behavior?
The sense I got from it was to not let the testing run away with you. To focus on the real behaviour. What is the point of creating tests for code that define a behavior that you don't have any story for? Excessive error handling can be a suspect in this category.
Aside from that I also got some repetition on the TDD cycle: Red, Green and Refactor. Focus on passing the test, save all refactoring for when it's green. To get ahead of yourself is like premature optimization, tempting but probably not a good idea...
The discussion then continued into whether Code Coverage is a good metric from a BDD perspective. When doing BDD/TDD the number will be high, but it will not tell you if you implemented functionality that was really required or not. You're goal is to solve the problem at hand, not achieving full coverage.
But there are uses for it, one opinion where that the coverage serve as well needed positive feedback for the developers, another that it can be a great tool for finding uncovered code that ought to be run by a test.
I wish that I'd had the time to stay after the dojo, but it was late and I had an early morning :(. It's not often that you get the chance to meet people that actually know their way around these concepts in real life!