Posts tagged BDD

After setting the environment and rethinking the workflow, it is time for some real work. So I started coding. I didn’t have to wait much for the first true effects.

I, as an architect, I decided to create process-based model. Then, as a coder, I begin coding some validation logic as an activity in the process. The activity takes a message as an input and returns true in it can be processed, false otherwise. Simple, isn’t it?

I didn’t have to come up with an API because the architect (myself, only with a different hat) had defined it already. So I proceeded to write the specification. After some struggle I realized that it will be really hard to write one. I had a dozen of validation rules written down in the analysis document and I wanted to write a specifications for each one of these separately. I don’t want that smelly code which creates a handful of  ‘exsample’ messages, validates them and checks whether result is the same as expected. That would be integration testing, not BDD-like specification.

The problem is that when rules are represented implicitly in the validation method (possibly as private sub-methods) if you want to check a single particular rule, you have to create a test object which is ‘almost valid’ — it passes all the rules except the one being tests. It is really awkward.

So, how can I do make code testable? For example, by making validation rule explicit. The need of writing a specification made me to think about validation in terms of rules to be specified and testes, not in terms of methods on a class. I created a new interface:

public interface IValidationRule
{
   bool Check(RequestForTransfer message);
}

The validation would have only to iterate through all the defined rules and check whether all of them are passing. More important, for each individual rule a specification can be written which directly implements the statements from the analysis document.

How would this end if I weren’t doing TDD? Almost certainly I would end up with validation logic encoded with one monolithic class, violating the Single Responsibility Principle. If I would have luck, individual rules would be implemented initially by different methods. But because this is not, by no means, a crisp design I would expect it to rot over time and validation logic rules to become be jumbled.

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.