This article starts with the assumption that testable code is better code. Its primary point against mocks, that mocks let you write tests without changing your

This article starts with the assumption that testable code is better code. Its primary point against mocks, that mocks let you write tests without changing your code, is dependant on that assumption. Without the assumption, there is no reason to believe that changing your code for the sake of tests is good or bad. I claim that that assumption is faulty. Code being easily testable indicates that it follows a certain set of good rules of thumb for writing good code. You're unlikely to find 500 line functions that encompass half of the program's logic. You're likely to find well delineated inputs and outputs of functions. The vast majority of the time, these are good things, and it's tempting to say that since writing testable code gave use these good thing, that only testable code is good. Or maybe you'd rather not leap that far — perhaps you'd rather only claim that as a rule, code should be written to be testable. It's not that it's an unreasonable rule. I'd be inclined to embrace it for novice programmers, since their judgement for what is and is not good code is lacking and they have to write tests regardless. Their code will probably come out better if they write for testing than if they try to use their best judgement. But once a programmer develops their judgement, they must use it. Programming is an art — a controversial statement, I know. It is not an art like music or painting or writing, it is more like architecture. Programming is about communicating simultaneously with humans and computers. Good code is that which achieves its technical requirements of reliability, performance, security, etc. in the way most accessible to a human. Good architecture is that which achieves its technical requirements of structural stability, cost-effective layout, energy efficiency, etc. in the way that best meets the needs of the people who will be seeing and using the space. There's nothing about testing in that definition. Optimizing code for tests is like optimizing a building for government inspectors. Yes, making all of the piping and wiring easily accessible via a hatch in the wall is a good thing because it will allow easier repairs and upgrades, but splitting the toilets into three different parts connected by rubber hose so that the inspectors can verify that the flush mechanism and the trap and what-have-you are all working properly independently would be inadvisable. I'm not going to attack the examples presented in the article because they are clearly a strawman. They serve to demonstrate the ideas the author sponsors rather than as a case study in how the author is right.