TDD story, part 2

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.