Re: Addin SetUp question

Hi Andreas, 

> Charlie Poole schrieb:
> > There is clearly a need for a class that represents all the 
> test cases 
> > run using the same test method. The current NUnit hierarchy is
> >    Test <-- TestCase  <-- TestMethod  <-- NUnitTestMethod
> >         <-- TestSuite <-- TestFixture <-- NUnitTestFixture 
> with only 
> > TestSuite's having child tests.
> >
> > I'm thinking of allowing all tests to have children and dropping 
> > TestCase from the hierarchy. A new TestCase class would be used as a 
> > child of a TestMethod and would represent the execution of the method 
> > with one set of arguments.
> >
> > Comments?
> >   
> How would the new class hierarchy look like?
>   Test <-- TestMethod <-- NUnitTestMethod
>                       <-- New TestCase (with arguments)
>        <-- TestSuite  <-- TestFixture <-- NUnitTestFixture

That's what I think at the moment. But I'm not sure TestCase
will really be a test at all, it may just be a set of args
to it's owning test method.

> The summary comment at the TestCase class says: "In the 
> present implementation, the only derived class is TestMethod, 
> but we allow for future test cases which are implemented in 
> other ways."
> 
> What could be other ways to implement a test case? Wouldn't 
> dropping the TestCase class from the hierarchy make it harder 
> to implement those other ways?

For example, you could implement a test case as a functor object.
Or as a bit of xml. 

However, TestCase is actually (in spite of the comment) optimized
for serving as a base class for a TestMethod. In other words, I
was trying to do a little design up front there and it doesn't
seem to have worked out. :-)

I'm currently thinking that we have a number of different
implementations of a Test, which are not necessarily related
to one another in an <isa> sort of way.

* TestMethod is an implementation as a method.

* TestFixture is an implementation as a fixture class

* TestSuite is an implementation as a general collection of tests,
which are run in sequence

These were arbitrarily divided into two main inheritance groups,
based on whether the test could contain other tests. But we 
just discovered that a testmethod can actually contain other
tests - at least I think that's the most convenient way to
look at it. 

So I'm thinking of dropping that approach and making the
hierarchy a bit flatter. I don't have the details yet, but
I'll post something when I do. Actually, what I'm working
on now is to remove the distinction between a TestCaseResult
and a TestSuiteResult, at least as they are used externally.

> I agree with you about the new TestCase class. But I think it 
> should be derived from NUnitTestMethod.

Let me think about that. I'm actually leaning toward aggregation
rather than inheritance here.

Charlie
 
> 
> Andreas
> 
> > Charlie
> >   
> 
> 



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/