This is strawman. If you phrase like this... "Make your code more testable by moving things that are cumbersome/expensive to test but extremely unlikely to bre

This is strawman. If you phrase like this... "Make your code more testable by moving things that are cumbersome/expensive to test but extremely unlikely to break into functions you don't test. Instead focusing your efforts on making the items that are likely to break easy to test" Phrased honestly it becomes more interesting discussion. I have worked on projects that had static analysis and high code coverage standards where code quality was abysmal, the product was barely functional, and development was paralyzed. I have also worked on projects that had none of those things but managed to have happy customers and quality product. What does this mean? It means that writing lots of tests is not enough to guarantee good outcomes. 1 great test is an asset, 400 bad tests are a liability. What does guarantee good outcomes is focusing on "equity". Does writing this test improve my equity position? If the answer is no or if you can't qauntitatively demonstrate the value in terms of opportunity cost then the answer is obvious...don't write the test. The current state of software quality at the development level closely parallels the plot of Moneyball. Consider this quote... "Okay, people who run ball clubs, they think in terms of buying players. Your goal shouldn’t be to buy players. Your goal should be to buy wins and in order to buy wins, you need to buy runs. You’re trying to replace Johnny Damon. The Boston Red Sox see Johnny Damon and they see a star who’s worth seven and a half million dollars a year. When I see Johnny Damon, what I see is an imperfect understanding of where runs come from” ― Michael Lewis, Moneyball: The Art of Winning an Unfair Game Many people try to buy quality with an imperfect understanding of where quality comes from.