Re: [Cppunit-devel] hierarchy sample bug...

[Baptiste L. <bl...@cl...>]

> Baptiste Lepilleur wrote:
>
> >     Well, another stuff to clean up would be that one. There is a well
> > hidden bug in this sample dealing with hiearchy:
> >
> > In the template BoardGameTest:
> >
> >     virtual void registerTests(CppUnit::TestSuite *suite)
> >     {
> >       suite->addTest (new CppUnit::TestCaller<BoardGameTest>
("testReset",
> >          &BoardGameTest<GAMECLASS>::testReset));
> >       suite->addTest (new CppUnit::TestCaller<BoardGameTest>
("testReset",
> >          &BoardGameTest<GAMECLASS>::testResetShouldFail));
> >     }
> > => BoardGameTest class will be instantiated by each test caller.
> >
> > and:
> > class ChessTest : public BoardGameTest<GAMECLASS> {
> > ...
> >     void registerTests(CppUnit::TestSuite *suite)
> >     {
> >       BoardGameTest<GAMECLASS>::registerTests(suite);
> >       suite->addTest (
> >         new CppUnit::TestCaller<ChessTest> ("testNumberOfPieces",
> >           &ChessTest<GAMECLASS>::testNumberOfPieces));
> >     }
> > => for ChessTest we have the parent class test caller instantiating
> > BoardGameTest instead of ChessTest !!!!
> >
>
> That is correct behaviour. The BoardGameTest checks invariants that should
hold
> for all BoardGameTest instances, including Chess objects. The testReset()
> method in BoardGameTest should equally apply to Chess objects. Overriding
> testReset() in ChessTest is a serious indication that the design of
application
> is flawed.
    I agree with that. Though in some case you might have some "template
method" (the pattern) in your test case. I can see that applying when you
have some specific behavior and want to factor some testing part. An example
that pop up into my mind would be testing visitor/strategy/builder. The
setup of each test may be identical and you would want to factor out those
part in a base class. Then, you would use the self-shunt pattern (having the
test case implementing the visitor interface...), and delegate part of the
actual test to the derived test case.

> However, there is one problem, which may be what you hint at: the current
> BoardGameTest implementation implies that all BoardGame classes have a
default
> constructor and need no further setup.
    This is indeed the main problem I see. You want the setUp() and
tearOff() method of your derived class to be called: initialization of the
"game" class, initialization of the default database connection for the
current thread...

Baptiste.
---
Baptiste Lepilleur <gai...@fr...>   http://gaiacrtn.free.fr/index.html
Author of The Text Reformatter, a tool for fanfiction readers and writers.
Language: English, French (Well, I'm French).