On Thu, 13 Apr 2000 06:42:06 -0500, "Michael C. Feathers"
>> I notice in the frameworks of TestUnit type programs,
>> the setUp tearDown methods are stored in TestCase.
>> Now it seems to me that you want these methods in Test,
>> since occasionally you want TestCase to have these methods), but very
>> often want TestSuite to hacve these methods.
>> So in both example you have a suite that has setUp and tearDown
>> Any idea why it is down the way it is?
>Basically, because those are atypical cases. Generally, you
>want to run tests in heretically sealed little containers without
>mutable state leaking across them because you want to be
>able to localize errors and keep them order independent.
But that's just the thing. There are some aspects of a test that are
mutable and others that are not. In particular the state of the
machine ( or system ) that runs the tests should be ( with few
exceptions ) unmutable.
Further you often need to modify the state of the machine for your
application to run ( for example you need to have some sort of
initialization, if you are using COM objects you need to register
them, if you are using CORBA and the CORBA services you may need to
start the services ). Afterwards you need to restore the state of the
I have seen a lot circumstances where developement and testing is done
on a machine that is in the state that it will run under. Then it gets
to the field, and there is something that is not right in the setup
and the customer has terrible problems, and the developers just don't
sympathise with the customer ( "it runs fine on my machine");
Development as I see it should go like this.
Machine in pristine state ( maybe development tools already on ).
Machine changes state to that needed for build.
Machine changes state back.
Machine changes state to that needed for testsuite1.
Machine changes back.
(BTW a good test is to make sure that the machine does change back,
sometimes an app doesn't do that. Bad form.)
The point is that those changes to machine state should be in a
setup,tearDown for TestSuite.
In fact now that I think about it, any state setup that is immutable
should be handled in the TestSuite rather then the TestCase.
Simply to make the tests run more efficiently.
And a little test to make sure an immutable state is imutable,
can be preformed in between tests. One more test!
Quote:>That said, people do need to be able to spoof databases
>and file systems, etc. In JUnit and CppUnit this is
>handled with the TestSetup class. It can decorate any test
>or test suite and bookend it inside a setup and teardown
I've never noticed it before. I will have to take a look at it.
It does seem to be a clumsy way of hanling the thing, and
it's not clear why setUp and tearDown are not virtual.