[Israel.pm] FW: Recommendation *Against* A Book: "xUnit Test Patterns"by Gerard Meszaros
RM07994 at freescale.com
Wed Apr 14 21:56:20 PDT 2010
I'll be happy to take you up on the offer to test-drive the book. Let's move to chat and discuss the logistics
SmartDSP OS Development Leader
SAVE PAPER - THINK BEFORE YOU PRINT
From: perl-bounces at perl.org.il on behalf of Shlomi Fish
Sent: Wed 04/14/2010 2:10 PM
To: Perl in Israel
Subject: [Israel.pm] Recommendation *Against* A Book: "xUnit Test Patterns"by Gerard Meszaros
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
"xUnit Test Patterns: Refactoring Test Code"
By Gerard Meszaros
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
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
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
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.
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 .
Perl mailing list
Perl at perl.org.il
More information about the Perl