Most of this makes enough sense to me, although it's hardly groundbreaking. But point number 6 completely eludes me. The argument is that procedural code is hard to test because ... it doesn't have a capacity for overloading in a test?! It's like the guy has never heard of a stub function before. Or formal verification. He thinks about testing only in terms of OOP, and hits a wall when he gets out of his comfort range that he thinks is a generic point of testing theory. This one was just awful, sorry.
(And it also seems to be introducing jargon that isn't required: what on earth is a "seem". Is he trying to say "seam"? Is that something I should have heard before?)
Point 8 ("favor polymorphism over conditionals") is also pretty sketchy. I buy the argument that this makes things more testable, I guess, but there's a long-understood readability argument against this kind of thing. That kind of hyper-pure-OOP leads to unreadable code that stretches even simple algorithms across dozens of classes and source files.
Agreed, static functions are (in my experience) much easier to test precisely because they generally have very explicit inputs and outputs, whereas instance methods are more likely to have "implicit" inputs in the form of object state and to have side effects, often in the form of modifying object state, rather than explicit outputs. My experience is that basically the closer you get to pure functional programming, with no global state and no side effects, the easier testing is.
The item about polymorphism strikes me as bogus too. But then again, I absolutely abhor mocks, because my experience has been that the mocks end up diverging from the real production code and you end up with either tests that don't break when the app is broken or tests that break when the app isn't broken, so optimizing for mocking is a horrible idea in my book.
Composition over inheritance is generally a good idea, but it is actually useful for testability, though not for the reasons the author mentions. Deep inheritance hierarchies make things hard to test because testing a leaf class in the hierarchy naturally means you're testing every other class up the chain, making it very hard to test just the code on that leaf class. Deep hierarchies like that also usually involve some contract between the different levels that's inherently hard to test for.
1. Good modular design is easy to write unit test for and doesn't require design pattern contortions. New is not a modern day plague to be avoided at all costs.
7. and 8. Taking things too far. You can not get a good design with a lot of hard and fast rules. But you might avoid terrible, impossible to maintain code. I think I see the problem now, google is about managing a whole lot of average coders, not great hackers.
Not the best software writing, kind of enterpise-ey sounding.
I also detect a hint of someone writes code, someone else writes test for it - BAD. Unit tests should be written by who ever wrote the code that is being tested. Preferably unit test first, then code.
Maybe I'm just charitably interpreting things, but #1 actually seemed OK to me. I think his point was that you want to separate the code that interprets your data from the code that builds your data so that they can be tested in isolation. That makes a lot of sense to me. The "bad code" end of this spectrum would be an algorithm in the application logic that can only run when connected to a fully-stocked external data store. That's not very testable; ideally you want to suck in a "test set" from a file or whatever and hand it to the algorithm instead.
But yeah, it's not as simple as removing "new" calls from application logic; it depends entirely on what you're trying to construct.
Well, there is only one Java book that I really liked. If you're into things like that then just go read "Effective Java" by Joshua Bloch (who also happens to be at Google at the moment). It's one of those rare books that doesn't have a catchy title but when you will read the whole thing you will realize that you've become a better programmer. Got any recommendations for another such book? Please shoot.
"The Pragmatic Programmer" by Andrew Hunt and Dave Thomas.
It reads a bit like "the 7 habits for effectice developers", except that it contains about a 150 "habits". I have wished many, many times that I could force colleagues to read this.
(And it also seems to be introducing jargon that isn't required: what on earth is a "seem". Is he trying to say "seam"? Is that something I should have heard before?)
Point 8 ("favor polymorphism over conditionals") is also pretty sketchy. I buy the argument that this makes things more testable, I guess, but there's a long-understood readability argument against this kind of thing. That kind of hyper-pure-OOP leads to unreadable code that stretches even simple algorithms across dozens of classes and source files.