Given that developer testing is the developers’ intentional and systematic employment of testing tools and techniques to achieve the highest possible quality of the software that they create, why would you do it? Isn’t it the responsibility of the testers to make sure that the created software is of high enough quality? Or, why would you burden the developers with additional tasks that obviously take time from the precious act of writing production code? (For variations of these two questions, look at the common questions.)

The motivation behind developer testing is three-fold:

There’s no time to test everything in every release

For the last decade, the release cadence has been shortened more and more. Scrum gives a team a time frame of one to three weeks. Kanban with good engineering practices results in weekly or daily releases. Continuous delivery enables multiple releases a day.

The fact that a team that delivers frequently can’t perform exhaustive manual testing and regression testing is called the regression testing challenge in the developer testing parlor. Therefore, the only way for the team to maintain rate of delivery and quality is to automate all checking and to ensure that there are as many automated regression tests as possible. Since a test becomes a regression test upon its first execution by the CI server, such tests are the very product of developer testing.

Only the developers can architect and design the software for testability

This is a more accurate way of saying that “quality must be built in, not tested in.” Testability is a quality attribute that needs to be weighed against other quality attributes. Developers are best qualified to determine what it takes to achieve good enough testability, because it’s a code-close quality attribute. Certain designs and patterns will lead to code that’s easy to test, whereas others will not. The developers will be the ones affected by such design decisions, because they’re eating their own dog food by writing tests. In other words, there is no one else who can make quality happen. Reviews or testing can demonstrate the absence of quality, but they can’t create it.

There are harder problems around the corner

Or, in fact, the harder problems are already here. Today’s software is a mix and match of various 3rd party services hiding behind service APIs. These services consume data from other services, they’re geographically distributed, and above all, they may be invoked by other software at an astounding rate. Think of high-speed trading algorithms. The user is no longer a human being. The user is a system with multiple cores and all the bandwidth it needs to wreak havoc to our public API. Add some AI to the mix and defects originating in badly trained neural networks, and we’ve got all the unpredictability we need.

In this light, we as an industry, must move past questions like “how many unit tests should I write?” or “what’s the difference between a mock and a stub?” Knowledge of testing techniques and proper use of testing tools, i.e. developer testing, must be part of the industry baseline, so that we can direct our attention to the hard questions.