To add to that - if the only thing keeping programmers from writing 1500-line monstrosities is the requirement to test their code, that's even more worrying, as anyone who's willing to write garbage like that is going to do a terrifically bad job of breaking out abstractions and modules, and now you have 1500 lines that are impossible to reason about split into 20 different classes.
I don't know... I find it much easier to reason about smaller methods. They didn't write just THAT one, there's plenty of code in that project... it's just a couple of methods that are horrible to work in.
It's absolutely true that all else being equal, it's easier to reason about smaller methods than larger ones. Most of the time though, what you're trying to reason about is an entire process rather than a method in isolation, and how small methods interact with each other is an important part of that.
It's absolutely true that there's almost never a time when a 1500 line description of a business process is the optimal approach. Conversely though, if abstractions are done poorly, those same 1500 lines split into a maze of different classes that don't cleanly abstract a particular, human-comprehensible part of the process can be just as hard to deal with.
