Developer testing is the simple, but logical, idea that developers should take responsibility and play an active role in testing their own code. We are nearing the 10th anniversary of JUnit—the unit-testing framework that, along with the rise in eXtreme Programming and other Agile methodologies, kick-started what I call, "The Developer Testing Revolution."
It's pretty clear that some sort of revolution is under way. More developers than ever are practicing and preaching the virtues of testing their own code. There are books, conferences, and dozens (if not hundreds) of websites and open-source and commercial tools aimed at developer testing. But despite all the passion, noise, and activity, developer testing is still far from a mainstream practice. It's the exception, not the rule.
When I look at the future of the developer testing revolution, I see three possible outcomes:
- Long-Term Defeat. The idea of developer testing was a noble but ultimately short-lived blip in the history of software development. Almost all developers went back to the old way of thinking—testing is for QA.
- Minor Victory. Developer testing does not go away entirely, but it remains a niche activity, practiced only by a devout minority of test-infected developers and organizations.
- Major Victory. Developer testing becomes a standard software development practice—the rule, instead of the exception. Releasing software without unit/developer testing is as unthinkable as releasing software without QA testing.
I'm rooting, of course, for the major victory, but am starting to worry that—unless we make some drastic changes in how we fight this revolution—it's not going to happen and developer testing will remain a niche activity. Here's what brought me to that conclusion.
In the past few years, I've noticed that while some developers are easily test-infected, others require longer exposure and some encouragement but eventually "get it," and one group seems to have a built-in immunity. It's as if developers have one of three possible testing genes:
- T1 Gene. Very susceptible to test infection. Show them a single unit-testing example and they get it immediately and start practicing it regularly and with great fervor. When time pressure hits, they fight hard for enough time to test and would rather quit than produce code without tests.
- T2 Gene. Somewhat susceptible to test infection. Show them how to use unit-testing frameworks and tools, give them some encouragement and enough time to appreciate the benefits and rewards, and eventually they will become test-infected. When time pressure hits, however, they often revert to no-test mode without too much kicking and screaming.
- T3 Gene. Apparently immune to test infection. The current motivation, approaches, and tools, are not adequate to get them to practice developer testing on their own with any regularity—if at all. Some of them would rather quit than have to write tests on a regular basis.
Based on years of observations, interviews, and direct experiences with hundreds of software engineers and managers, I've concluded that developers with the T3 gene outnumber those with the T1 and T2 genes. This spells trouble because I've also found that when developers become architects or managers, they bring with them their attitudes toward developer testing. And a T3 manager is not going to provide an environment where the T2 (those requiring some time and encouragement) can become test-infected. This might explain why developer testing is still practiced by a minority of developers in a minority of organizations.
Is a major victory still possible for the developer testing revolution? I believe so. I'm optimistic because I know that most T3 developers believe that the idea of developer testing is intrinsically right. They just think that it's too hard or time consuming, and have a hard time practicing it—especially when it comes to the more dogmatic and extreme forms, such as Test Driven Development (TDD).
We need to acknowledge and accept that the motivations, approaches, and tools that excite T1s and eventually test-infect T2s, are not working on T3s. Developer testing practices such as TDD may be the way to go for many, but they are not the way to get T3s on board. To infect those resistant developers, we need to start small, have fewer rules, and give them better tools.
