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

Levenglick Dov-RM07994 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
 
Best Regards,
Dov Levenglick
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
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 .
_______________________________________________
Perl mailing list
Perl at perl.org.il
http://mail.perl.org.il/mailman/listinfo/perl


More information about the Perl mailing list