On 8/14/06, Stewart Stremler <[EMAIL PROTECTED]> wrote:
begin quoting guy keren as of Tue, Aug 15, 2006 at 01:27:04AM +0300:
> On Mon, 2006-08-14 at 15:02 -0700, Stewart Stremler wrote:
> > begin quoting guy keren as of Tue, Aug 15, 2006 at 12:13:22AM +0300:
[snip]
> > > in other words - start writing _something_. you can always delete it
> > > after a few hours, and even then you learned something. once you start
> > > writing unit tests, it usually just flows easily, and you realize that
> > > all the tests look the same.
> >
> > doTest() {
> > setup();
> > test();
> > display();
> > cleanup();
> > }
>
> this is not the way to write _automatic_ tests. instead, you should:
[ugly example deleted]
Oh, god, no. What a good way to miss the point. And you were so close.
Guy's example was not ugly. For a little bit more code, it was a lot
more sophisticated. It correctly exited when any phase of the test
failed, and gave a useful message to the developer.
I've used this idea of "create a basic test framework and evolve it as
much as a particular project needs it to evolve" more than once. And
right of of the gate, I support setUp, test, and tearDown. Geez, it's
*easy*.
I do prefer to catch exceptions rather than rely on a return value,
since you'd probably want to catch exceptions anyway given that a
programming error could lead to one at any time.
try:
self.setUp()
except Exception, exc:
print 'Test %s failed in setUp() due to: %s: %s' % (
self.name, exc.__class__.__name__, exc)
return
Too much code? Oh, well. I like to share.
"It usually just flows easily."
Show. The. Flow.
(Thus the mock-code. No parameters, no returns, no decisions. It's
not even psuedo-code. Flowcharts are too annoying in ASCII to do often.)
I could easily read the flow of Guy's code. Except for all those weird
curly brackets. ;-)
> and wrap this up with a little engine ("that could") that runs a list of
> (parametrized) tests.
Exactly.
> of-course, the devil is in the little details (e.g. how to set-up, if
> some function requires a complicated setup?)
Indeed.
Indeed.
> > A framework is nice, but lack of same shouldn't keep one from writing
> > a test -- although it often does. :(
>
> a framework is simple to write. lack of it should encourage you to write
> something quick and evolve it as your tests evolve.
You needs a test and a way to run the test. A "framework" may be
overkill.
Eventually, you'll WANT that framework... But waving a hand and claiming
it's "simple" is ... well ... simplistic.
If you'll eventually want the framework, why not make a framework
version 0.0? Even with its shortcomings, it would probably be easier
to evolve into a real framework than hardcoded test cases. That's *my*
point. And probably Guy's.
-Chuck
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
