What you're doing is similar to what I call Maintenance-Driven Development (https://taylodl.wordpress.com/2012/07/21/maintenance-driven-development/ https://tay

What you're doing is similar to what I call Maintenance-Driven Development (https://taylodl.wordpress.com/2012/07/21/maintenance-driven-development/ https://taylodl.wordpress.com/2012/07/21/maintenance-driven-...). Put your testing effort in things that are likely to fail and don't insist on 100% code coverage, not even close. For example, I hear people complain all the time about how stupid it is to test getters/setters. So don't write tests for them (even better, don't implement them - but that's another story!) They're not likely to fail. Maybe if a code's cycolomatic complexity score exceeds a certain value then test it (consider refactoring to reduce the complexity too!) In my decades of software development experience I can tell you most developers have a good "feel" for what needs to be tested and what doesn't. Listen to them - they're usually right. If they're not then you'll catch it on the break-fix.