[qmtest] context passed among tests?

[eichin at metacarta.com]

> Those are both important design decisions.

Always a good thing to hear.

> (Prerequisites are not supposed to be used for ordering so much as for
> optimization/diagnosis; if simple test X fails it may not even make sense
> to run big test Y.  Or, the opposite -- if big test X passes, you may want
> to skip small diagnostic tests Y and Z.)

So prerequisites can be thought of as "short cuts" - it wouldn't be
wrong for qmtest to just run everything, in any order, and ignore
them, but they let useful results be reported faster.  Got it.

> There are of course games you can play (use the filesystem, modify the
> classes directly, global Python variables, etc.) that you can use to
> do cross-test communication, but we're not going to make it easy. :-)

Ah, the fine principle of "make it easier to express the right thing
than to express the wrong thing" - C being the usual counterexample :-)

> In the abstract, resources are just an optimization -- you do some set-up
> once and share it for lots of tests.  A correctly implemented resource
> could be run once for each test that needed it, or just once for all of
> those tests; the only difference should be how long it takes the tests to
> run.  So, having one resource depend on others is no problem, that's just
> allowing the resources themselves to be optimized in a similar way.

It's just an optimization from the viewpoint of the tests; it does
impose an ordering (or rather, a nesting) on resource construction,
though.  I guess it's sufficient for the test "plan" phase to come up
with a set of "edge" resources, and then work "outward" from there;
you might handle lifetimes as an optimization, simple reference counts
should be enough for correctness.

Ok, so I think I have an idea of the direction to go with short-term
cheating, so that I can easily sync back up later.  Thanks.  _Mark_