Please pardon me while I rant a bit…
How many times have we heard this response when we press our co-workers to test the code they are writing. This argument is often made when the team is up again tight deadlines and excessive pressure from management for delivery. I’ve even made the argument myself before, but find it increasingly harder to say it with a straight face.
Way back in 2000 I was given a copy of “Extreme Programming Explained” as a going-away present. I was leaving a research organization here in San Antonio to cut my teeth with a local start-up. Our shop was reasonably mature (rated CMM-3) and I had learned quite a bit about Software Engineering in a relatively short period of time. That said, the ideas in this books really got me thinking…and it seemed to help sate my hunger for a more lightweight process that would better fit my now environment.
Among the first practices that I started to grapple with was testing. I had experience with SilkTest, but I wanted tests that were closer to individual units. I first started with my own home-made test fixtures and had limited success…a few years later I was using VBUnit and NUnit..and I was becoming test infected. In spite of my love for working with tested code, I still found myself arguing that I didn’t have time to test when under the gun. It was about the 4 year mark that I began to shift my view.
Now, I think that abandoning testing due to time constraints is reckless and irresponsible. I sometimes catch myself thinking that I don’t have time for test writing, but I soon find myself proving this argument wrong. Often people who don’t have time to test will waste hours debugging code that they are desperately trying to force into production. This code ends up being brittle and costly to produce anyway. Corners cut on testing ultimately translate into a more costly investment in debugging and code fixes. When recently confronted with a peer who claimed that they didn’t have time to test, I angrily responded that I spent two days trying to get code working that was breaking due to a careless mistake in their code (which I then had to help debug). They didn’t have time not to test!
Granted, learning to test adequately is not a trivial task and can sometimes take years to really get right. This effort (and investment) is well worth the trouble as it will not only produce better code, but will most often transform how the programmer sees code. Although I sometimes have to work pretty hard to “tame” legacy code, the investment rarely proves to be wasteful…rather it saves time and money. Testable code is maintainable code. Maintainable code is cheaper code. As developer teams become better at testing they also become better at producing quality code.
After about over a decade of coding professionally I’ve settled on the credo: “No tests, no trust”.