Developer testing is the developers’ intentional and systematic employment of testing tools and techniques to create testable and maintainable software with as few defects as possible.
Unlike spontaneous ad hoc unit testing of things that are easy to test, developer testing requires a structured approach and mastery of several core competencies, of which understanding testability drivers, fundamental testing techniques and unit testing are the most important.
Developer testing is not a new concept or technique. Rather, it’s a structured approach to quality-related activities performed by developers. Here’s how it relates to some other familiar terms.
Developer testing and Unit testing
Unit testing is an integral part of developer testing. After all, the majority of all developer tests are most likely to be unit tests. A developer who works intentionally and systematically with unit tests will rely on established testing techniques to create meaningful and comprehensive unit test suites (as opposed to testing the easy and obvious). Such a developer will also constantly look for tools and libraries that will make the tests more self-documenting and easy to read.
Developer testing is more than unit testing. In most cases, developers need to supplement their unit tests with higher-level tests, such as integration tests and end-to-end tests.
Developer testing and Testing
Here “testing” means traditional manual testing. Nowadays it’s common to make a distinction between testing and checking. The former requires skill, experience, imagination, and creativity, whereas the latter is boring and repetitive and best left to a machine. In organizations where developers just write code, without actually verifying that it works, testing is reduced to checking and quality assurance is used to compensate for an inferior development process. An explicit goal of developer testing is the developers automate all the checking, so that actual testing can take place.
Sometimes, the terms prevention and detection are used instead. Developer testing is all about prevention.
Developer testing and Continuous Delivery
Developer testing is a prerequisite for continuous delivery. As a team starts to aim for a shorter delivery cadence, it soon realizes that it has to automate all of its current tests, and that new functionality has to be developed in tandem with developer tests (checks). There’s simply no way to handle regression testing manually with frequent releases.
Developer Testing and the Agile Testing Quadrants
The Agile Testing Quadrants is a versatile model that can be used for many things. Among others, it provides a landscape of quality-related activities that an agile team needs to navigate. Developer testing overlaps very nicely with this perspective. Here’s how.
The Agile Testing Quadrants & Developer testing
By definition, developer testing is mostly a technology facing activity that guides daily development work. Therefore, it covers the entire lower left quadrant.
Walking upwards in the model, we see that developer testing also covers part of business facing testing activities that guide development. The most natural application is using various BDD-style frameworks and related glue and automation code to create more complex tests. Actually, all “behind the scenes” kind of code produced from the perspective of this quadrant is, in one way or another, a product of intentional developer work. What developer testing will not help with in this quadrant is coming up with the scenarios and stories, deciding on what A/B tests to launch, and evaluating the input from any prototypes. These are activities which developers are indeed involved in, but they require additional expertise and team members with different roles.
When applied in the lower right quadrant—technology facing tests that evaluate—developer testing translates into technical tests executed in the CI suite (or at special occasions) written by developers. Typically these would be performance tests, but secure programming and automated vulnerability checking would also qualify here. What’s outside the scope of developer testing is Black Hat style penetration testing, security audits, and scripted performance tests launched from multiple sites (the kind you’d buy from a vendor that specializes in this.)
As always please keep in mind that reality is more complex than a triangle overlapping four squares and that the scope of your developer testing activities will depend on the context: domain, team composition and maturity, organizational culture, etc.