Anyone who has ever managed a project has probably had to make a decision between delivering at high speed, high quality, or low cost: As the saying goes, you can only pick two. This is usually as true for the delivery of software as it is for anything else, but mounting pressure to digitally transform and continuously deliver updates has made speed a default requirement for most organizations. This leaves a choice between quality and cost, which often comes down to a decision about testing.
Testing—especially unit testing—has been an underappreciated stage in the software delivery lifecycle (SDLC) for decades. It’s historically been slow, resource-intensive, and less interesting than the development of new features, which may be why the primary motivation to write unit tests for many developers is external pressures, e.g. management or customer demands, rather than their own conviction that it’s worth doing. Within organizations that enforce code coverage targets, mandated manual testing can feel a lot like being told to eat your vegetables because they’re good for you.