Reading time: 4 – 6 minutes
I’m a ThoughtWorker. ThoughtWorks is changing the way that enterprise software is delivered. And with that we take firm stances on heavily debated topics. In previous jobs I’ve tried to push test driven development, unit testing, code coverage metrics, continuous integration… all controversial ‘best practices’. Results were mixed.
A few weeks ago I was at a large web 2.0 social networking site working with selenium grid automation. They were great clients, fully receptive to automated testing. Next week I’ll be heading to another leading internet company to work triage:
- Work on troubled teams whose code is poorly tested
- Enable groups to test legacy code
- Attempt to spread a pervasive test driven mindset.
I’m joining a senior team of ThoughtWorkers and in preparation I’ve thought of various arguments I’ve heard (or used myself) against testing code. I’ll be challenged working with these very experienced people, but I am eagerly looking forward to the experience.
Adding all these tests only makes more code to maintain, debug, and write. This can’t be good – I want less work, not more!
Rebuttal: Would you agree code and requirements often change? Would it be valuable if something could automatically and accurately catch bugs introduced with changes? How about if the original developers are no longer on the project? Testing can enable less work — in a dynamically changing environment. Immediately the work is greater, but over time it is less.
Ok, fair enough, there are some good reasons to do this. BUT, when I want to change something later, I now have two points of failure – the code I’m changing, and all the tests that depend on that code. I haven’t really bought myself all that much security, because if my tests don’t catch the problem well, I’m just as hosed as if I had no tests. Source: first comment from here
- You get better and faster with tests the more you write them.
- By writing tests you further understand the business domain and craft a better thought out solution.
- Whenever making changes in the future you actually have 1 + n points of failure. That which you are changing plus the other interacting systems within the code. By writing tests you will automatically catch the interactions, as well as the initial point of failure. Sure the tests need maintaining, but now with two things to maintain, you catch (almost all) these failure points.
I generally think testing is a good idea. But I’m stressed out, I’ll get to it later… tomorrow I’ll add tests… as soon as I get this working
Rebuttal: Take a page from Agile Software Development: Principles, Patterns, and Practices by Robert C. Martin.. He argues for refactoring but since the two concepts are so tightly entwined, I think the argument applies here:
“Refactoring is like cleaning up the kitchen after dinner. The first time you skip it, you are done with dinner more quickly. But that lack of clean dishes and clear working space makes dinner take longer to prepare the next day. This makes you want to skip cleaning again. Indeed, you can always finish dinner faster today if you skip cleaning, but the mess builds and builds. Eventually you are spending an inordinate amount of time hunting for the right cooking utensils, chiseling the encrusted dried food off of the dishes, and scrubbing them down so that they are suitable to cook with. Dinner takes forever. Skipping the cleanup does not really make dinner go faster.”
Skipping testing does not really make software development faster, because changes are guaranteed. (You’ll have to cook another dinner eventually). Without an easy way to baseline and build upon existing code, time is spent bugfixing that could instead be adding features or writing new tests.
I’m awesome. I don’t write bugs. So I don’t need tests.
Rebuttal: Great. I’m excited to be working with you. I’m sure I’ll be able to learn a great deal. I imagine you like fresh challenges. And in six months or a year this current project won’t be as interesting to you as it is today. In fact, you’ll be on to something more challenging and worthy of your awesomeness.
So that means someone else — possibly a junior developer — will be maintaining and working on this code. Without tests, they will be frequently seeking your assistance and guidance to prevent bugs. This is not what you want, is it? You want new challenges, not constantly being hassled by old code. So write the tests now to ensure your ego and intellect can move forward to bigger and better things.
Elaborating and paraphrasing, Neal Ford argued at eRubycon 2007:
Now I look at not testing as professionally irresponsible. I’m paid to create software, to deliver on a client’s business needs. If I don’t rigorously and automatically ensure I have accomplished this with the minimum amount of bugs — I am committing malpractice.
What arguments have you encountered, and how have you responded?