The Butler Did It

I have been using Spec Flow for the last few months as my feature specification framework, but sometimes the output I want to assert can be very repetitive, a simple example of this the string calculator kata.

Each part of the add feature specification is actually simply checking the return value given a specified input string.

using a traditional spec flow scenario specification it would look a bit like this

lots of repeated code here, even using a regex to simplify the step definitions our feature file is going to get very long and difficult to maintain.

To help with just this sort of problem, Spec Flow supports the gherkin table construct this allows us to define the scenario steps separately from the data required by the steps, in this case our data is the input string “<input> and expected result <output>.

The steps are defined by a scenario outline with place holders for each of the required data values, and the data itself is defined in an examples table structure with a column for each place holder separated by the “|” pipe character.

When the scenario is run it loops around replacing the place holders with each row of data, until either there is an error (fail) or it runs out of data (success).

The step definitions for the scenario outline are exactly the same as for a normal step definition, using a regex to extract the values passed by the framework, and handing them into the method definition as parameters.

Using the table structure is a very powerful way of displaying the data required by a specification, and controlling the number of scenarios that need to be written.

Ok so that got your attention, from someone who has spent the last few years jumping up and down about unit testing, now he has problems with it!

Actually no, its not the tests, it’s the what.   Going back over some old code the other day, and by old I mean about three months old, I had a problem, after some fairly heavy refactoring which involved combining one repository class with another, so that the repository link-to-SQL matched the database, where as the repository API matched what the business layer wanted, I noticed some push back from the tests.

The refactoring should have broken a single group of tests, those that relied on the original repository methods, but instead may tests across the application were failing, what made it a bit worse was the fact that the mass of tests made it difficult to actually predict which tests should fail because of the changes made, an important distinction, when refactoring you need to know what you expect to happen, against those cases where you have actually broken something without realising.

So what was the problem.  I have lots of tests, (a good thing), virtually all the code is covered, if I were to run a code coverage tool across the code, then the result would be in the high 80%-90% range, (you can very rarely reach 100%), but, some of these tests are fragile, which means that the test is tightly bound to the structure of the code, also some of my tests actually cover the same code many time, and these tests maybe in different test fixtures, which also added to the confusion.

So what has happened? Well all the code written in this application was test driven using the Behaviour Driven Development style of testing, and I made the error of treating my tests as inferior to the production code, I refactored the production code,  but didn’t treat the tests in the same way.  To be totally honest I am not sure that I refactored the production code as well as it could have been, which could also lead to the problems I was having.

So what have I learnt, when doing test driven development, one of the most important steps, which is actually very easy to miss is refactoring, you write a failing test, then make it pass, the temptation is to then write the next test, I find, by this point, the next test is in my head, I know where to go next! Its so important to stop at this point, write that test down on paper if you have to just so you don’t forget it, don’t write it in the code, because you will be tempted to then make it pass, as you should  never refactor on a red line!, which will start the whole process off again, just stop. Look at your production code, and refactor it, run the tests again, then go and look at your test code, all your test code, and refactor that, make sure that each test is still valid, that you are not covering the same area twice, don’t be afraid to delete, combine, or change tests, as your code develops, and changes, so should the tests, they are not immutable, they are the wrapping around your production code, and like a wrapping paper around a parcel, the shape should reflect the shape of the code they are covering.

This is another thing those silly katas can help with, just the simple muscle memory of refactoring after each test, both in the production code and in the test code can be practiced, and the action of red, green refactor will become second nature, which will help the tests to stay fresh and meaningful.

“Quality is never an accident;  It is always the result of high intelligent direction and skilful execution;  It represents the wise choice of many alternatives”

found by corey haines in a muffler shop!

Testing like it or not is now mainstream, just about every version of visual studio 2010 has the ability to run native Microsoft unit tests, and there is a plethora of unit testing frameworks out there to choice from for those who don’t like the Microsoft “way”.   So there is really no escape, and as we move towards automated rollouts, and a defined build cycle, the requirement to “prove” that the code works has moved from being nice to have being a strict required!

TDD is a technique, which along with traditional design  methods and programming patterns, help the developer produce well structured, encapsulated code, which is easy to maintain and extend.  TDD on its own will not create great code, but it is the corner stone on which great code is written,   One of upshots of working in the TDD way is that the time spend debugging is reduced, after writing code there is no debugging time, which can over a project lifespan save a considerable amount of time, and money.

TDD is based on three simple rules, which lead to the programmer too writing code in a tight loop between the test class and the production code.

Rule 1: You are not allowed to write any production code, unless it is to make a failing test pass.

Rule 2: You are not allowed to write any more of unit test code than is sufficient to fail, and not compiling is failing.

Rule 3: You are not allowed to write any more production code than is sufficient to pass the one failing test

This is not easy (nothing worthwhile ever is!), So like any skill to be effective it must be practiced, and that is what the code kata’s are about, these are simple small programming problems, where the solution is easy to arrive at, but the process of repeating the kata trains the muscles to that you instinctively start coding by writing the test first, and building from there.

Next time some code examples!

Well I have at last put my code where my mouth is 😉 and uploaded a screencast, this is of me carrying out a simple code kata, something I have been doing in private for a few months now, I started with Uncle Bobs bowling kata, and then got introduced to Roy Osherove’s String Calculator kata.

The idea of the kata is that you memorise it, and then do it every day, I spend 25 minutes doing the kata first thing in the morning, the idea is that it builds muscle memory, and the habit of test driving your designs, which I have found to be very useful.

One final part of the kata is to perform it in public, so you can get feedback and gain insight into your code style, with the aim of improvement, so with that in mind I present for your perusal and comment

The String Calculator Kata.