[qmtest] writing composite tests

[Mark Mitchell]

> > We've intentionally made it hard for one Test to get its hands on
> > another Test.  The reason is that tests should be independent of
> > another; this is another design goal.  If tests are not independent of
> > one another then running one test is no longer a well-defined operation;
> > each test is potentially dependent upon context created by other tests.
> 
> Ok, understood. I should have been clearer: I didn't mean to suggest any
> dependency relationship between tests, but only between test *classes*,
> so I can use the 'composite' design pattern. From a user's perspective
> there would only be a single test, and the result would contain all the
> relevant information about passes or failures.

Ah, I see.  

But, why do you have to change the Run interface?  The Run method in the
composite class could simply pass its result parameter down to the
contained test classes.  Wouldn't that work?
 
-- 
Mark Mitchell
CodeSourcery, LLC
mark at codesourcery.com