Re: [Cppunit-devel] Release 1.8.0 ?

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

Quoting "Steve M. Robbins" <ste...@vi...>:

> Hi all,
> 
> I discovered that cppunit 1.6.1 won't install properly on a system
> that lacks "doxygen".  So I started a 1.6 branch in CVS and committed
> the fix.  I'll make a 1.6.2 release on the weekend if I get time.  Is
> there anything else that ought to be addressed?
> 
> To get the 1.6 branch, I'd suggest finding a clean spot and doing
> a new checkout.  You need to give the "-r BRANCH_1_6" option to
> cvs:
> 
>     cvs -d xx...@cv...:/cvsroot/cppunit \
> 	checkout -r BRANCH_1_6 -d cppunit-1.6branch cppunit
> 
> Remember that commits in that directory will go on the BRANCH_1_6
> branch, *not* on the main trunk.
> 
> 
> 
> 
> On Mon, Oct 08, 2001 at 02:21:38PM +0200, Baptiste Lepilleur wrote:
> 
> >   Well, there a load of new stuffs... If everything is ok on the
> >   Unix side, we should try for the release, no ?
> 
> Eh, well I can build it and "make check" reports no failures (104
> tests), so things look good on the unix side.  That's only one
> platform (Linux), mind you.  Since we've recently run into problems
> with Solaris compilers, it would be nice if a Solaris person would
> test things out.
> 
> Any takers?
> 
> We could make a 1.7.0 tarball as a snapshot of the current development
> tree -- would that help?

  We need to readd throw() to Exception::what(). I add mistakenly removed it 
during my quest to find the Exception::operator =() problemon VC++, and forgot 
to change it back.

> >   What do you think Steve ?
> 
> I don't understand what you've done!  :-)

  Which feature are you refering to ?

> I'm getting a bit worried that the "test runner" stuff is getting out
> of hand.  Once upon a time I posted a sketch of how to rework the
> classes to (in my view) drastically simplify the "runner" code and
> make it trivial to implement output by writing a simple "listener"
> class.  See 
> 
>   http://www.geocrawler.com/archives/3/6780/2001/7/0/6126118/
> 
> What do you think of the proposals contained therein?  How have
> your recent changes modified this?

  There is simplification, but some complexity have been "added" to stay 
backward compatible. I would go for only the following functionnality:
  - give me the list of the failures,
  - give me the list of testcase that has been run,
  - give me the number of tests run,
  - give me the number of failures.

  => before, TestResult stored two kinds of failures: failure and error. 
Because of this, there was a lot of code duplication in "user" code of 
TestResult. Now, failure kind is stored in TestFailure.

> And there is also the issue of TestCaller versus fixtures, c.f.
> the thread starting from
> 
>   http://www.geocrawler.com/archives/3/6780/2001/7/0/6126116/

  Your test runner proposition sound goods. My self, I found two kinds of user 
for TestResult:
  - Listeners, which provides dynamic feed back during the run (progress)
  - Outputters, which print report based on the list of failures and run tests 
(since they might print them in an order that don't match the run, grouping all 
the sucessful tests together for example, they do their 'thing' after all the 
tests have been run).

> I'd really like to have this cleaned up for 1.8.  And hopefully I'd be
> able to understand CppUnit well enough to write some documentation ...

  I can't see that done really quickly. So I would prefer to go for 1.8 
(release often), then tackle that issue. The CompilerOutputter and assertion 
helper are so useful! I can't see how anybody can live without them ;-)

  Baptiste.

---
Baptiste Lepilleur <gai...@fr...>
http://gaiacrtn.free.fr/index.html
Language: English, French