Simple BDD/TDD

Todays theory is most tests and specs should be very short (2-3 lines), have at most a setup for context establishment, avoid the majority of test framework features as they should be used as an exception and not as a rule.  Note: I practice BDD nowadays and do not like using the term “test”, but these rules apply for BDD as well as TDD, and I imagine most of you practice TDD so I’ll be using primarily TDD terminology.

If you look at my first attempts at TDD they are very similar to my current BDD work with only changes in language. But the contexts, conditions and tests are similar. Most importantly they’re easy to read. They’re all very short, very descriptive, make limited use of arguments in the NUnit Attributes, and make very limited use of mocking.

Of course along the way I went down all sorts of terrible wrong paths, and with the help of Gerrard Meszaros plus some of my own experimentation I’m much happier with the time it takes to implement tests and the limited pain in refactoring my code.

Bad ideas I had along the way include:


Summary point avoid some of my mistakes, if you write short unit tests now..thats probably a good thing. If you are struggling with testability of your classes and you find your tests getting big, try and stop, sit down and make sure you are testing “one thing” and not really a big thing with many small pieces.