This is clearly an opinion-piece and as such I guess it's not terrible, but it certainly has enough points to disagree with. From quickly reading through it, f

This is clearly an opinion-piece and as such I guess it's not terrible, but it certainly has enough points to disagree with. From quickly reading through it, for instance I found the following things directly objectionable: > "Unit testing was a staple of the FORTRAN days". Such an attempt at discrediting something can be applied to anything, and it comes off as disingenuous, dishonest. > "Unit tests are unlikely to test more than one trillionth of the functionality of any given method in a reasonable testing cycle. Get over it." ... Trillion is not used rhetorically here, but is based on the different possible states given that the average object size Who says you have to test the method? Who says you're not allowed to test functions which operate on a known, closed subset of data? False dichotomy and plain bad math. > If you find your testers splitting up functions to support the testing process, you’re destroying your system architecture and code comprehension along with it. That may be right. Or it may be possibly completely backwards. It's quite impossible to tell really, without asking why they are splitting up those functions. If people do this for gaming some sort of system about "at least 80% coverage" or whatever, then clearly you should ask why people feel the need to game the system. Gaming the system, no matter what aspect, leads to bad choices. Me however, I'm not splitting up my functions to game the system. I'm splitting up my system to separate data-retrieval from data-processing (so I can directly test processing without depending on whatever retrieval depends on). I'm splitting up my functions to give them name and intents, this makes the code speak much clearer about what it is doing and why. The function name should be "what". The contents should be "how". Basically I'm splitting up my function for good reasons. If a function is long enough to contain enough actions, intermediate variables, loops and conditionals so that you need to stop thinking about and wonder what they do, and what their role is inside that function... That functions should be split up, because you do not have a clear "what" and "how" delimiter. And guess what? That also assists testability. You can test that the "how" correctly assesses the "what". This is not destroying your system. Some of the functions you end up with may even turn out to be reusable across the class/system, meaning you increases consistency and correctness as a result too. Again: This is not destroying your system. Quite the opposite. I could go on, but I'm just at the 4th page of 21, and my comment is already the biggest in the thread, and I'm not planning on making a blog-post length response. Just saying this document is severely biased, contains factual errors and is not a good thing to rely on to present an argument.