RE: [Cppunit-devel] Some Questions

[Michel A. <Arm...@si...>]

> > 1. CppUnit::Test
> > Why are the find-related methods not const? Shouldn't they? 
> I feel const
> > find-methods are somewhat more intuitive, aren't they?
> 
> They all store the test in a TestPath, which store non const 
> pointer on the
> traversed test, or returns a non const pointer on a test. 
> Since TestPath is
> mainly used to run test (non const) method, it makes sense (at least I
> beleive so). Let's me know if you have another point of view 
> on the suggest.
> At first I wanted those methods to be const too.

I'd suggest, to make the find() methods const anyway. I'd also leave the
returned information non-const. This of course makes it neccessary to
const_cast the returned information (pointer to Tests etc.). In this case I
think a const_cast is acceptable, because the find-methods themselves do not
modify the Tests; just subsequent calls on the result of the find-methods
may modify the Tests.
Any other opinions around here?

> 
> >
> > 2. CppUnit::TestDecorator
> > This class doesn't delegate _all_ the methods. IMHO, in 
> order to have a
> > completely transparent Decorator, it really should delegate 
> all methods.
> > What do you think of this?
> 
> I guess that makes sense. At the current time, it delegates 
> all the virtual
> pure method. Though I haven't found much use for that class 
> yet (I used it
> for the first time in the first 'writing' of DllPlugInTester 
> were I need to
> pass Test to the TestRunner without them being destroyed 
> after the run).
> 
> > 3. CppUnit::TestCase
> > Maybe we can enhance the run() method, so that it can also 
> properly (with
> > SourceLine information) catch failures in both setUp() and 
> tearDown()?
> 
> To you means catching possible assertions made in 
> setUp()/tearDown() ? We
> don't have the SourceLine information for other exception.

This is exactly what I meant. Setup() and tearDown() methods may also
contain code which may not execute as expected. To be able to insert some
CPPUNIT_ASSERTs there would certainly help a lot.

> 
> >
> > 4. CppUnit::TestSuite
> > There is an unused m_name in this class 
> (CppUnit::TestComposite already
> > defines this member; and actually uses it ;-)). Let's 
> remove that unused
> > member?
> Removed it. Left over of when I pulled up those into TestComposite.
> 
> > 5. CppUnit::TestRunner
> > Neither CppUnit::TextUi::TestRunner nor the MFC-based 
> TestRunner reuses
> the
> > generic TestRunner in some way. Is that intended? Or are there some
> > refactorings pending? Just wondering...
> TextUi can be derived from CppUnit::TestRunner (only some 
> default listener
> and outputter are added). The Mfc TestRunner could be derived 
> too, it use a
> similar 'test' suite management for added test, but the run() 
> method does
> not have anything in comon (does not take a TestResult, or a 
> test path)?
> Plus the test can be run many times... I don't really know 
> what to do with
> that one.

> 
> > I could do (2.) - (4.) my own and submit the changes; I 
> just don't know
> how
> > to best submit these changes. (I don't have cvs-access here :-(.)
> 
> Fixed. You should have CVS access now.

No, its more a problem of being behind a nasty firewall... :-(

Armin.