From: djberg96@... (Daniel Berger)
Date: 2004-06-15T03:18:40+09:00
Subject: Re: [ANN] celsoft.com/Battery 0.1.1

<nasty emails snipped>

/me grabs everyone by the ear...

First of all, everyone settle down.  This list has been extremely
friendly in the past, I don't want to see it degenerate into a
flamefest.  At least, not unless we're flaming Perl or Python. 
KIDDING!

Anyway, I don't really care about the definition of the word
"arbitrary" and whether or not it was used correctly.  The tests in
TestUnit run in alphabetical order and to me that's just the way it
is.

I ran into this a while back and my initial solution was to append 01,
02, etc, to the method name to get it to run in the order I wanted,
e.g. test_01_foo, test_02_bar.

As I've gotten into unit testing I've realized something.  It changes
the way you think about writing code, and thus the way you *design*
code.  When I write methods, one of the things I consider is, "how
easy will it be to test this method by itself".  This leads into why
people think that the order your unit tests will run shouldn't matter
- each method should be testable on its own *to make it easier to
test*, which in turn leads to smaller chunks of code, which in turn
leads to easier maintainability (in theory).  It's not "just because".
 I don't know if I'm making sense here, so let me quote a paragraph
from "Learning to Love Unit Testing" by Dave Thomas and Andy Hunt,
STQE, Vol 4, Issue 1, p.38:

"..., tests affect the *design* of your code.  When developers get
into the habit of unit testing everything, they discover that some of
what they write is hard to test.  Sometimes they find themselves
having to construct elaborate frameworks to test a single method. 
Sometimes they find that the method is hard to test because it handles
many different cases.  And sometimes things are hard to test because
the code that does the real work is buried deep in the program's 
guts.  Are these reasons not to test?  On the contrary, this kind of
discovery is one of the most valuable effects of testing, because the
tests are telling you secrets about the structure of the code.  List
to the tests and refactor (a fancy way of saying restructure)
accordingly.  The code will be better for it.  Methods will have
clearly defined functions.  The class hierarchies are flatter, and
they more accurately reflect the business value of the application. 
there's less coupling between classes.  All of this makes the code
easier to write and simpler to maintain."

Back to ordering the unit tests.  Sometimes this is probably
unavoidable.  If that's the case, so be it.  The unit testing police
aren't going to come get you.  Just make sure you document it
somewhere.  However, when you come to a point where you think you'll
need your tests in a certain order, you should at least consider
whether a Mock Object wouldn't be a better solution.

What does this have to do with Battery?  Man, I don't know.  I lost
track of why I started on this thread about 2 paragraphs ago. ;)

Dan