TestingUnits (JUnit,CppUnit ...)

TestingUnits (JUnit,CppUnit ...)

Post by Thaddeus L. Olcz » Fri, 14 Apr 2000 04:00:00



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.

Two examples:
1) Creating objects out of DB query's. To observe that this mechanism
is working write you want to:
a) Load the Db with certain data (setUP)
b) Run the tests
c) Remove the extraneous data.

2) Writing code that searchs a certain filesystem for appropriate
files:
a) Create a filesystem to test on.
b) Run tests
c) Remove the files and directories.

So in both example you have a suite that has setUp and tearDown
methods.
Any idea why it is down the way it is?

 
 
 

TestingUnits (JUnit,CppUnit ...)

Post by chong_the_b.. » Fri, 14 Apr 2000 04:00:00




> 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.

> Two examples:
> 1) Creating objects out of DB query's. To observe that this mechanism
> is working write you want to:
> a) Load the Db with certain data (setUP)
> b) Run the tests
> c) Remove the extraneous data.

> 2) Writing code that searchs a certain filesystem for appropriate
> files:
> a) Create a filesystem to test on.
> b) Run tests
> c) Remove the files and directories.

> So in both example you have a suite that has setUp and tearDown
> methods.
> Any idea why it is down the way it is?

I'd say that TestSuite has both of the cases you mention.  TestCase is
obviously more abstract than TestSuite . . . just from what you posted,
I'd think TestSuite is a container of some kind.

Each TestCase then has a different setUp and TearDown that is
implemented in the concrete TestCase that inherits from TestCase.  So:

TestCase DBTest;
TestCase FileTest;

// ...
// So eventually:

DBTest.setUp; // etc. . .
// Test.runTest with TestSuite then makes sense

Chong.

Sent via Deja.com http://www.deja.com/
Before you buy.

 
 
 

TestingUnits (JUnit,CppUnit ...)

Post by Michael C. Feather » Fri, 14 Apr 2000 04:00:00




Quote:> 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
> methods.
> 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.

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
pair.

Michael

---------------------------------------------------

Object Mentor Inc.  www.objectmentor.com
Training/Mentoring/Development
-----------------------------------------------------
"You think you know when you can learn, are more sure when
you can write, even more when you can teach, but certain when
you can program. " - Alan Perlis

 
 
 

TestingUnits (JUnit,CppUnit ...)

Post by Thaddeus L. Olcz » Fri, 14 Apr 2000 04:00:00


1) From your post it is abundantly clear that you have not ever used
one of the "TestUnits". You have no idea what the layout of the
classes are.In other words you have no idea what you are talking
about.

2) Why the hell would anyone talk about something they don't know
anything about. I personally try to avoid it as much as possible,
becauwse I think it makes me look stupid.

 
 
 

TestingUnits (JUnit,CppUnit ...)

Post by toddh.. » Fri, 14 Apr 2000 04:00:00






> > 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.

> 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.

> 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
> pair.

They aren't really atypical in more complicated testing contexts.
In my project testing simple things is atypical.
I added setup and teardown to TestSuite. I also add a
properties configuration block to the test suite so tests could
share a common global configuration. I also added pointers so
a test would know it's test case and it's test suite and could
get common configuration. For complicated distributed tests
there is a boat load of configuration necessary and lot of
setup necessary at a lot of different levels, especially when
you try and run distriubuted systems in various configurations.

As i had to basically rewrite CppUnit for our environment this
was not a big deal. You should make any changes that would
be helpful for your project.

Sent via Deja.com http://www.deja.com/
Before you buy.

 
 
 

TestingUnits (JUnit,CppUnit ...)

Post by Thaddeus L. Olcz » Fri, 14 Apr 2000 04:00:00


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
>> methods.
>> 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
machine.

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.
Build.
Machine changes state back.
Machine changes state to that needed for testsuite1.
Runs 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.)
... testsuite2,testsuite3....

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
>pair.

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.
 
 
 

TestingUnits (JUnit,CppUnit ...)

Post by Michael C. Feather » Fri, 14 Apr 2000 04:00:00




Quote:> 1) From your post it is abundantly clear that you have not ever used
> one of the "TestUnits". You have no idea what the layout of the
> classes are.In other words you have no idea what you are talking
> about.

> 2) Why the hell would anyone talk about something they don't know
> anything about. I personally try to avoid it as much as possible,
> becauwse I think it makes me look stupid.

Thaddeus,

I usually let vitriol just roll off the net, but in this case, I'll
just say that I wrote CppUnit, and far from looking
stupid, Chong made some very good inferences from
our discussion.

Regarding your other post, yes, that is one way of
doing it.. getting your machine in and out of the
state that you need for your tests.  However, in
my experience, it is far better to do whatever is
possible to make sure that you are independent
of the environment outside of your tests.  If
this means spoofing more, so be it.  Luckily,
if you practice test first design, you end up
with code that is far more decoupled than it
would be if you decide to test after the fact.
It just hurts to do otherwise.

The case you mentioned, where it works on
the test machine but not on the users' machine really
is something that you should discover during
functional testing rather than unit testing.

Michael

---------------------------------------------------

Object Mentor Inc.  www.objectmentor.com
Training/Mentoring/Development
-----------------------------------------------------
"You think you know when you can learn, are more sure when
you can write, even more when you can teach, but certain when
you can program. " - Alan Perlis

 
 
 

TestingUnits (JUnit,CppUnit ...)

Post by chong_the_b.. » Sun, 16 Apr 2000 04:00:00




> 1) From your post it is abundantly clear that you have not ever used
> one of the "TestUnits". You have no idea what the layout of the
> classes are.In other words you have no idea what you are talking
> about.

Forgive my eagerness . . . thought the post was more general than
specific as the follow-up posts show.

Quote:> 2) Why the hell would anyone talk about something they don't know
> anything about. I personally try to avoid it as much as possible,
> becauwse I think it makes me look stupid.

Yeah . . . that makes sense . . . anyhow, back to the bong . . .

Chong.

Sent via Deja.com http://www.deja.com/
Before you buy.

 
 
 

1. CppUnit and autoconf/make - OT

Hi,

Apologies for OT but I was hoping to capture the greatest pool of
CppUnit users here.

Simple question. Has any one used CppUnit in anger, ie. in a largish
project with multiple directories, and used to the GNU build tools
(autoconf and automake).

I can get my application to build but when I run it, I am informed
that 0 tests have run OK?? It is as if my test suites have never been
linked? If I build each module serperately and link them then the
tests run fine, but you can imagine how long the build takes each
time.

Regards,

J.

2. strdup/xstrdup

3. CppUnit problems; std::exception::operator= slices?

4. Connecting your Palmpilot on your craddle to the net using RAS

5. Interesting CppUnit breakage.

6. So much for that (ml.org)

7. Cppunit

8. Best price for 4Plex?

9. JUnit Framework description

10. Test cases organization (JUnit, Ant...)

11. JUnit: Generic interface testing

12. Experience using CPPUnit Testing Framework with Borland C++Builder?

13. Setting up CppUnit with GUI-Testrunner