TDD story, part 1

Recently I was assigned to a new project. It seemed to be yet another simple application so, to add some spice, I decided to do it the TDD/BDD way. This is a story which documents my efforts.

Work environment

Configuration of work environment was harder then I expected. Forcing Visual Studio 2008 to work properly with two monitors was a must. I really wanted to run my tests as easily as possible and have the results displayed on side monitor immediately. Instead of working IDE, I ended up with Visual Studio crashing and restarting itself whenever I tried to run the code. Finally I figured out which window caused the problem. It seems that if you use multiple monitors, you can’t use Test View. At least closing it helped in my case.

The good thing is I finally, because of lack of Test View window, learnt some keyboard shortcuts concerning running automatic tests. From the other hand I would have to do it anyway, if I wanted to run the tests after every change in code. Now, I am starting to make Ctrl+R,A a habit, just like Ctrl+S: write some code, save it and run all the tests.

You are not allowed to write any code before writing a failing test

This statement is very well known and accepted but is, in fact, completely misleading. I am sure that those of you who do TDD on a daily basis understand it correctly. But someone, like me, who wants to start his test driven journey, thinks reads it like this:

1. Start writing a test.
2. Accept the fact that R# makes all your code test red and you lost your Intellisense.
3. Use R# to create missing classes and methods. Make methods throw NotImplementedException.
4. Run the test. Wow! It fails! I finally can write some code! Hurray!

Which, of course, is completely wrong. Thanks to Derick Bailey and his great TDD blog post series I woke up very quickly. Instead of the workflow above, I started to practice something like this:

1. Experiment with the API of a new piece of code (this step is actually a little bit controversial, but I don’t care)
2. When satisfied, write it down with empty method bodies or returning default hard-coded values
3. Write a specification of behavior for that API. Start with one statement.
4. Run the specification. It fails because the assertion expected a correct value but default or hard-coded one was provided.

Start with something simple

I really really love the idea of Behavior Driven Development — specify instead of test. But I don’t want to start my TDD/BDD journey by installing the latest and coolest unit testing frameworks. I don’t want to teach my colleagues how to use it and I don’t want to scare them with these sophisticated tools. I want them to grasp the principles of TDD/BDD, not learn how to use infrastructure.

So I stick with plain MSTest. Yes, you can do BDD and write specifications of behavior using MSTest. Is is somewhat awkward, however, but is definitively possible and doesn’t break any corporate rules and habits.