Re: [Cppunit-devel] TODO Documentation

[Baptiste L. <gai...@fr...>]

Can you look at http://gaiacrtn.free.fr/cppunit/index.html and let me know
if you find the GUI and the creatin test case/ways of macros description
clear enough ? (they need update but the basic haven't changed since then).

See below.

----- Original Message -----
From: "Robert Wenner" <ro...@po...>
To: "Baptiste Lepilleur" <gai...@fr...>
Sent: Wednesday, March 27, 2002 1:26 PM
Subject: Re: [Cppunit-devel] TODO Documentation


> On Wed, Mar 27, 2002 at 12:25:06PM +0100, Baptiste Lepilleur wrote:
>
> > Can you specify "this or that" ? I'll make a TODO list, and hopefully
will
> > be able to explain some (not that the NEWS file contains some info).
> In the cookbook I would put
> - how to create simple test cases (with CppUnit namespace)
>   - test case using only CPPUINT_ASSERT
>   - test case using CPPUNIT_ASSERT_EQUAL
>   - advanced assertions with the CPPUNIT_ASSERT_MESSAGE

- creating custom assertions using Asserter. (or should I put this at the
end ?)

> - Helper Macros for convenience
> - Creating a suite
> - Composing a suite from more suits (i.e. compose tests for n modules to
>   form a big test for the whole program)
> - customizing output using an user defined TestListener
>   - how to write the TestListener (subclass of TestListener)
>   - how to hook it in
> - how to use the GUI
>   - MSVC++ special stuff
> - other custmization stuff I haven't understood yet

That layout looks good to me. You I keep the current cookbook, or scrap some
of it (subclassing TestCase for example ?)

>
> Class documentation would also be helpful, I think it's hard for a
> beginner to distinguish between TestResult, TestListener and
> TestRunner and where to subclass for what reason.

From what I read below, it's seems that you are indeed refering to
TestResultCollector (TestResult have been splitted in two classes since
1.7.3).

I'm thinking of renaming TestResult to TestController. It's managing the
TestListener, and in the short future, it'll provide a way to
protected/decorate and test (for timing, COM initialization, and specific
exception capture). Would that help ?

> As far as I understand TestResult does have to be the base class for
> defining a fourth condition aside Success, Failure, and Error.
> TestListener would be to process test results (e.g.
> pretty printing, handing them to another program, ...).

In the current version, TestResultCollector is a TestListener. TestResult no
longer holds the result of a test run.

> TestRunner would be subclassed for e.g. adding a Method to be called
> once for the whole test process. (And TestSuite would be subclassed to
> define methods to be called before and after the Suite / Fixture. Or
> do you inherit from TextFixture for that?).

I guess you would have to subclass TestSuite to do that. Though is
"dangerous" since that setUp()/tearDown() would not be called when executing
a single test case with the GUI.

>
> BTW is there some kind of CPPUNIT_FAIL or do you have to use
> CPPUNIT_ASSERT(0) ?

  There is a CPPUNIT_FAIL, name CPPUNIT_FAIL (amasing, isn't it ?) ;-)

  Check file NEWS for new things you might have missed.

Thanks for your feedback Robert,
Baptiste.

>
> Robert
>