In late December last year, I moved from finance IT into retail IT for the first time in 10 years. One of the first things I wanted to do in my new role was to give a flavour of how I saw the importance of tests in software development. Given the issues with attention span and signal to noise ratios on office emails, I decided to post the following notice in the toilet cubicles of all our development offices....
A Call to Arms
We need a change. A change in the way we approach test code. Test code is just as important as the code we release to production. It's really meta-code, in that it's code that describes the behavior of production code. It has the power to either constrain or free the evolution of the production code. It dominates the architecture.
For example, how often have you seen a piece of production legacy code where everyone knows how it 'should' be written, but can't take on the refactoring work because the tests don't adequately verify expected behavior? The refactoring gets left because it would simply carry too much risk. And this is just one way in which poor or missing tests impact not only upon the correctness of the system, but its ability to change.
Anyone who's been developing for 10 years or more will have come across a number of instances where systems are replaced with functionally equivalent yet more (scalable, secure, insert your architectural dimension here) solutions. If you have come across this, now might be an appropriate time to pause for a minute and consider exactly what prevented the original system from evolving to accept these new architectural or functional requirements. With the exception of replacement of vendor products, it's most likely that it's down to an inability of the current codebase to adapt to the new architectural constraints or functional requirements.
Many architects concern themselves with scalability of a particular system architecture and may only give a passing nod towards the importance of tests. There's a certain irony to this, since there are natural limits to how well any particular system architecture will scale. Only through tests that adequately describe the functional requirements and architectural constraints will we have the necessary safety net to truly respond to scale by evolving the production architecture itself.
In short, test code matters. It really matters. It matters in a way that makes the production code seem almost trivial and replaceable. And that's a Good Thing since it means we can respond to change. I want us to start giving some real care to the unit and functional tests, just as we currently do with the code that will be deployed to production.
So, as you leave this cubicle and go back to your desk, I would ask two things of you:
1. Wash your hands
2. Shift your perspective on the relative importance of test code.
Interested in hearing more and shaping the software we create?
Search the wiki for Software Craftsmanship and come join our Community of Practice.