[Israel.pm] Recommendation *Against* A Book: "xUnit Test Patterns" by Gerard Meszaros

Shlomi Fish shlomif at iglu.org.il
Wed Apr 14 04:10:16 PDT 2010


Hi all,

I see that I've started a silly discussion about how to write dates, so here's 
something more on-topic. This is a book review for this book I've started 
reading:

"xUnit Test Patterns: Refactoring Test Code"
By Gerard Meszaros
http://www.amazon.com/xUnit-Test-Patterns-Refactoring-Code/dp/0131495054

I admit I haven't finished it (and likely don't intend to) - I'm only in page 
134 or so out of 833 (!) pages. Nevertheless, my sister told me she always 
gives a book a hundred pages to pique her interest and if it doesn't she gives 
up.

In any case, I bought this book because I wanted to improve the method I've 
been using to write automated tests and see what other people can say about 
it, and because it received good reviews on Amazon.com. This book failed to 
meet my expectations: I still didn't get to the patterns themselves, and it 
spends many pages discussing the minutiae of the testing philosophy with many 
forward and backward references. It gives a lot of advice, but with too few 
stories (see http://www.joelonsoftware.com/articles/BestSoftwareWriting.html 
), a lot of tech and Extreme Programming jargon, and too much of it to be 
effective.

I think the only concrete thing I can remember from all of it was saying that 
when something breaks in your code, only one unit test should fail, and given 
that I don't consciously often draw a line between the types of tests in my 
code, I've noticed it wasn't the case with my t/*.t tests and really do not 
care more for it being the other way.

To further elaborate on that, I've decided that I was probably writing 
automated tests in the right way for me: a test that I needed whether a unit 
test, an integration test or a system test, using Test::More and other tools, 
while tending to write a lot of repetitive code but eventually extracting it 
into subroutines, modules, and sometimes even objects. With all due respect 
for testing code (and I can never go back to manual testing), I feel it's just 
means to the end of creating high-quality software, and not something that 
needs obsessing with. Just freakin' write the freakin' tests and go on with 
your life.

So I decided that continuing to read this book would not be the right choice.

If anyone from here wishes to borrow this book, I'd love to give it away for 
trial, and if you're interested in keeping it, we can negotiate a price. (It's 
in very good condition.). You'll have to pick it up from my apartment in Ramat 
Aviv Gimel (Northern Tel Aviv) because it's a heavy book.

Regards,

	Shlomi Fish

P.S: another aspect of the book that disappointed me was the poor quality of 
the drawings and diagrams. This is in comparison to a different book I've 
started to read right now ( http://www.algorist.com/ - so far I like it and 
can recommend it), which has very good diagrams. 

-- 
-----------------------------------------------------------------
Shlomi Fish       http://www.shlomifish.org/
"Star Trek: We, the Living Dead" - http://shlom.in/st-wtld

Deletionists delete Wikipedia articles that they consider lame.
Chuck Norris deletes deletionists whom he considers lame.

Please reply to list if it's a mailing list post - http://shlom.in/reply .


More information about the Perl mailing list