jeffesp's posterous

Pandora Radio

The Trip-Hop station on Pandora rocks. I guess not literally.

Thoughts on TDD and BDD

I just finished reading Martin Fowler's Mocks Aren't Stubs. This is a great document because it gives some names to things that I hadn't been able to name before. Classicist vs. Mockist TDD is a key distinction that we have been struggling to define as we develop more concrete testing methods at work. To know that other people, who know what they are doing, have also dealt with it helps us to know that we are not just making things up.

My key conclusion from this is that I follow a Classic TDD model. I don't want to care about the behavior of my methods and therefore I am not going to do strict mocking where I verify that certain methods have been called. The interesting wrinkle here is that I really want to use a mocking framework for the ease with which I can create a stub or dummy object. This isn't well supported in all of the frameworks, but I have heard that Moq is going to be what I want to look at.

Fowler's article linked to Dan North's BDD introduction. I hadn't understood BDD before, and I can't claim that I really do at this point, but there is some interesting content in this introduction. The first few paragraphs of this description really seems to address a number of problems that I have had with TDD and unit testing in general. Here are the questions he poses:

• Where to start?


• What to test and what not to test?


• How much to test in one go?


• What to call their tests?


• And how to understand why a test fails?

I had yet to come up with satisfactory answers to these question. But North has a simple answer for all of them: write your test names like sentences. If my test class is named FooLookupTests and my test method is named FindFooByIdTest(), I can write "Foo lookup - find foo by id." When the test classes and methods create this structure, then I am working in the right direction. When they do not create this structure, then I need to review what I am testing and refactor my tests and possibly the code under test to follow this guideline.

After this simple suggestion, North goes on to point out how he developed the BDD method from this insight. On my first evaluation of this description, I do not like it. While I like North's initial insight and I think his answer to the questions above is very insightful and useful, I can't see myself adopting a full BDD process.

Update: my coworker John mentioned that the main point of North's introduction is more that the test methods need to be named in a testShould...() format. Certainly the BDD people would argue that you are doing it wrong if your test methods aren't of this form. For my purposes, I don't think this is strictly necessary, but is a useful point to keep in mind.