

Writing Testable Code - haasted
http://googletesting.blogspot.com/2008/08/by-miko-hevery-so-you-decided-to.html

======
ajross
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.

~~~
biohacker42
Same here, and also:

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.

~~~
ajross
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.

~~~
biohacker42
Maybe I've just seen one too many factory factories.

------
simplegeek
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.

~~~
haasted
"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.

<http://www.pragprog.com/titles/tpp/the-pragmatic-programmer>

------
swombat
Paragraphs, please!

