cppunit-devel — CppUnit Developer Mailing List

Re: [Cppunit-devel] 1.6.0 is released!

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

----- Original Message -----
From: "Steve M. Robbins" <ste...@vi...>
To: "CppUnit Development" <cpp...@li...>
Sent: Monday, September 24, 2001 6:23 AM
Subject: [Cppunit-devel] 1.6.0 is released!


> I'm happy to report that version 1.6.0 is now available on the
> SourceForge web site.

    Great! I integrated it to our project at work, it works fine.

> The only significant change from the last snapshot is a last-minute
> bugfix from Baptiste.  (The other changes were to doc files.)
>
> The CVS tree is synched up with the release version, and tagged (tag
> REL_1_6_0).  My immediate plans are to wait and see what bug reports
> come in.  I am prepared to make a 1.6.1 release as soon as necessary,
> and generally I plan to keep making 1.6.x releases as necessary to fix
> bugs.

    Well, there are bugs in cppunittest/TestCallerTest (as well as a few
memory leaks I did not spot last time), is does not check correctly the
expected exception stuff. Should that go in 1.6.1 or 1.8.0 (with the
exception enhancement I proposed in another mail)?

> In the meanwhile, we should kick around ideas for 1.8.0.  I generally
> favour the "release early, release often" policy.  How about the rest
> of you?  If we go that route though, we need to be aggressive in
> limiting what changes will be made for 1.8.  Let's hear ideas!

    What is your definition of often ? once a month, biweekly, weekly ? As
time go, we should strengthen our test suite. Whenever a bug is found, we
should try to write a test for it. I already did it for the TestCaller
thingy.

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

[Cppunit-devel] TestFailure, TestResult and TestListener revision proposal

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

    When I wrote Qt TestRunner last week, something stroke me as unnecessary
complex: TestResult result !

    Failure fall in two types:
    - error: failure, which cause is a catch (...) in either setUp(),
runTest() or tearDown(),
    - failure: failure which cause is CPPUNIT_ASSERT or expected exception
not caught (in fact, any exception of type Exception caught in setUp(),
runTest() or tearDown() ).

    Here all is fine. Error indicate a "severity" flag: the application flow
is broken by an unexpected exception (or a structure exception on Windows, a
crash if you want).

    The complexity come in the fact that distinction is never stored in
TestFailure. Instead, you must rely on the method you override ( addError()
or addFailure() in either TestResult or TestListener ). Add to that the fact
there is no way to obtain a list of all failure. You need to grab two
distincts lists, meaning you got an unordered set of failures.

    The proposed change are:

    - add bool TestFailure::isError();
    - add void TestResult::failureAdded( TestFailure *failure), called by
both TestResult::addFailure() and TestResult::addError(). [Is that one
really needed?]
    - remove std::vector<TestFailure *>& TestResult::errors()
    - remove TestListener::addError() and TestListener::addFailure()
    - add TestListener::failureAdded( TestFailure *failure )
    - have TestResult::addError() and TestResult::addFailure() adding
failure in m_failures.
    - add TestFailure *TestResult::failureAt( int index )
    - something need to be done about int TestResult::testErrors() and int
TestResult::testFailures() to avoid confusion. Remove testErrors() and have
testFailures() report the number of call to both addError() and addFailure()
?

    => That make it possible to use TestResult as a model for the list of
failures (avoiding some code duplication).
    => Make it much easier to work with TestResult. Most of the time, you
don't care weither it was an error or a failure.

    So what ?

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

Re: [Cppunit-devel] 1.6.0 is released!

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

----- Original Message -----
From: "Steve M. Robbins" <ste...@vi...>
To: "CppUnit Development" <cpp...@li...>
Sent: Monday, September 24, 2001 3:49 PM
Subject: Re: [Cppunit-devel] 1.6.0 is released!


> On Mon, Sep 24, 2001 at 03:15:01PM +0200, Baptiste Lepilleur wrote:
>
> >   Hey, talking about doc, is there a place where we could put up the
WIN32 FAQ
> > (got again a FAQ #1 question, and the cockbook will lead to FAQ #1
question
> > (crash if RTTI is not enabled)).
>
> The only FAQ of which I am aware is the three questions at the bottom of
> INSTALL-WIN32.txt :-)
>
> A more visible FAQ would be a great addition.
>
> If you wish to start one, my suggestion is to put it in the doc/
> directory of the sources.  I can make arrangements for it to get
> automatically updated to the web page cppunit.sf.net every so often.

    HTML format or text, or ... ?

> >   Another point, I'd like to be able to generate documentation with
doxygen on
> > WIN32. To do so I would need to have a version Doxyfile.in where "macro"
stuff
> > have been replaced. Is there a way to do that in an automatized fashion
?
>
> Baptiste, maybe it is time to bite the bullet and join us in
autoconf-land!  ;-)

    Well, If you were to give me the @@topdir@@ & co value (or semantic), it
could probably be automatised with a simple search and replace (a slighty
easier solution ;-) )

>
> Seriously, there has been work to generate Visual C++ project files
> automatically using a configure script.  I'm not sure how viable it is
> at the moment, but I'm certainly willing to do everything necessary to
> support you, short of actual testing (I have no MSwin machine).  The
> last message I saw about this is at
>   http://mail.gnu.org/pipermail/automake/2001-August/009531.html
> if you wish to follow it up.

    I'll try to give it a look. I tried to use TMAKE (from Qt, a free perl
tool to generate Makefile using template) to generate project file from the
project definition instead of a Makefile for Qt TestRunner, but it
conveniently forgot the Enable RTTI and Enable Exception support flag... May
be qmake fixed (Qt 3.0) that but it still isn't available on Windows...
Generating Makefile work file on the other hand.

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

[Cppunit-devel] CppUnit 1.8.0 features...

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

    Depending on how soon you want 1.8.0 to be, here is a list of feature
that are simple to implement:

    1) CPPUNIT_TEST_EXCEPTION( method, ExceptionType)
    2) CPPUNIT_TEST_FAIL( method )
    3) add a flag to TestFailure distinguishing error/failure, retain only
one collection to store result
(see other mail)
    4) CPPUNIT_TEST_SUITE_NAMED_REGISTRATION( TestFixtureType, SuiteName ) :
register the fixture's suite in a suite of the specified name.
    5) Qt TestRunner (I've got it working, need feedback and help to use
TMAKE to build a library instead of an application)
    6) ASSERT_EQUAL support for two differents compatible types

    1 & 2) are already done (need to be integrated & documented though).
    3) is a bit of work, but not much.
    4) only really need the macro declaration & documentation
    5) need some collaborative work, meaning unpredicatable amount of
time...
    6) need to find suitable traits. Probably some discussion there...

    Those are mostly simple stuff that hinder me, and other I guess, when I
use CppUnit...

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

Re: [Cppunit-devel] Small patch for cppunit on Alpha Tru64 Unix 5.1

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

Resurecting an old thread in answer to [Is that really "RogueWave"?] ;-)

=> if you look carefuly, what RogueWave doc say (below) is that the problem
is related to DEC cxx, not RogueWave, but to compile RogueWave STL, you must
also define the flag.

Baptiste.

----- Original Message -----
From: "Baptiste Lepilleur" <gai...@fr...>
To: <cpp...@li...>
Sent: Monday, June 11, 2001 4:21 PM
Subject: Re: [Cppunit-devel] Small patch for cppunit on Alpha Tru64 Unix 5.1


> Quoting Petter Reinholdtsen <pe...@hu...>:
>
> > [Steve M. Robbins]
> > > Petter: what feature is missing if __USE_STD_IOSTREAM is NOT defined?
> > > Does the problem appear in Tru64 4.x, by chance?  I have a 4.0f system
> > > (on which I could work out a configure test), but no 5.x systems.
> >
> > The code refuses to compile if it isn't defined.   Apparently, the C++
> > library on Tru64 5.x (I know nothing of Tru64 4.x) require one of two
> > defines to allow iostreams to be included.  I choose the Standard C++
> > define when compiling cppunit.
> >
> > A simple compile test in configure.in should solve the problem.
> >
>    I searched RogueWave documentation for that symbol. Here is what I
found
> (excerpt of Tools++ 7.1.1 toolread.doc):
> ----------------------------------------------------------
>                    ***************************
>                 ****   DEC C++ on OSF users   ****
>                    ***************************
>
> Tools.h++ is certified for:
>   Digital UNIX V4.0F for DEC C++ V6.1, with POSIX threads
>     NOTE: Either DEC or RW Standard Library can be used
>
> 1. If you compile Tools.h++ with the DEC Standard Library, Tools.h++
> will use the old-style iostreams rather than the new iostreams
> specified by the published C++ Standard.  The reason for this is that
> DEC cxx uses the old iostreams by default and requires the user to
> put -D__USE_STD_IOSTREAM in the  cxx command line in order to get
> the new iostreams.
> ----------------------------------------------------------
>
> So it seems to be a platform specific "feature" ;-)
>
> Hope this help,
> Baptiste.

---
Baptiste Lepilleur <ble...@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).

[Cppunit-devel] Exception & TestCaller bug

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

    Yesterday I found a bug in test caller. When an expected exception
wasn't caught, it did:
throw new Exception(...) instead of
throw Exception(...).

    I went down to the test suite to see why it was not detected. Result:
forgot to put a test case for that one. I'm in the process of correcting
this, but there is no way I can safely distinguish if "new Exception()" or
"Exception()" was thrown. There can only be distinguished by the message.

    This can be easily corrected. Exception can be subclassed (as is done by
NotEqualException). What I propose is to define a set of class to
distinguish the exception cause. Here is my proposal:

    - Exception : base class for all exception. Contains a message

    - FailureException : thrown when an CPPUNIT_ASSERTxxx fails, or when an
expected exception is not caught (this is a form of assertion)

    - NotEqualException: a specialization of FailureException for
CPPUNIT_ASSERT_EQUALxxx. Contains expected and actual string.

    - UnknownErrorException: thrown when something is caught in a "catch
(...)"

    - SetUpException : thrown when a exception is thrown by setUp().
Contains caught exception.

    - TearDownException : thrown when an exception is thrown by tearDown().
Contains caught exception.

    What do you think ?

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

[Cppunit-devel] TestCase that expect exception...

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

  Well, starting on new stuff functionnalities agin...

  TestCaller provides a way to expect macro. Yesterday I try to had a new macro:
CPPUNIT_TEST_EXCEPTION( method, ExceptionType), that would construct a 
TestCaller that would expect the specified method to throw an exception.

  I remembered the discussion we had about using a decorator to do that. I 
tried to create such a thing, but...

  What we want to decorate is TestCase::runTest(). Ideally we would create a 
ExceptionTestCase class that would decorate a TestCase, and forward setUp(), 
tearDown() to that testcase, and implement runTest() by forwarding to the 
testcase's runTest(), but expecting it to throw the exception.

  The problem is that TestCase is using the TemplateMethod pattern and runTest
() is protected.

  So I fell back on the current solution on use the TestCaller to do that. But 
that raise the inconsistancy issue between the testcaller (can expect 
exception), and the testcase. I also needed to add a template method to 
TestSuiteBuilder (with a dummy pointer to pass the exception type). 

  Notes that I'll probably add another macro:
  CPPUNIT_TEST_FAIL( method ), which expand to CPPUNIT_TEST_EXCEPTION( method, 
CppUnit::Exception). That one is actually of use when you test testing classes 
(you write an utility class that compare some expected and actual data 
structure, and is complicated enough that you want to test it).

  For short term, I'll report the change using that solution (it's hidden 
behind macros) to the CVS tree when the branch is done.

  Let's talk about long term...

  The core of the problem is that the only way to change the behavior of 
TestCase::runTest() is by subclassing.

  This go with another issue I have: I want to be able to extend the framework 
to to include new recognized exception class in TestCase::run() (for example, 
using RogueWave library, you get RWXMsg as a base class instead of 
std::exception).

  An obvious way to do both would be able to pass a "decorator" to TestCase::run
() that would be used to run the actual testcase:

class TestCaseDecorator
{
public:
  virtual setUp( TestCase *test );
  virtual runTest( TestCase *test );
  virtual tearDown( TestCase *test );
};


TestCase::run( TestResult *result, TestCaseDecorator *decorator )
{
  // [...]
  try
  {
    decorator->setUp();
    try
    {
      decorator->runTest();
    }
    // [...]
    decoartor->tearDown();   
  }
  // [...]
}

  The decorator would probably not be a paremeter. I could TestResult becoming 
something more than just "result", and handling a "stack" of decorator (you 
could push a decorator that would decorate all previous decorator).

  If we had something like this, we could:
  - handle new exception type.
  - handle "expected exception" using decorator: subclass Test, and push the 
decorator that expect the exception in run(), then call the decorated test run
() method, pop the decorator.

  Baptiste.

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

Re: [Cppunit-devel] 1.6.0 is released!

[Steve M. R. <ste...@vi...>]

On Mon, Sep 24, 2001 at 03:15:01PM +0200, Baptiste Lepilleur wrote:

>   Hey, talking about doc, is there a place where we could put up the WIN32 FAQ 
> (got again a FAQ #1 question, and the cockbook will lead to FAQ #1 question 
> (crash if RTTI is not enabled)).

The only FAQ of which I am aware is the three questions at the bottom of
INSTALL-WIN32.txt :-)

A more visible FAQ would be a great addition.  

If you wish to start one, my suggestion is to put it in the doc/
directory of the sources.  I can make arrangements for it to get
automatically updated to the web page cppunit.sf.net every so often.

 
>   Another point, I'd like to be able to generate documentation with doxygen on 
> WIN32. To do so I would need to have a version Doxyfile.in where "macro" stuff 
> have been replaced. Is there a way to do that in an automatized fashion ?

Baptiste, maybe it is time to bite the bullet and join us in autoconf-land!  ;-)

Seriously, there has been work to generate Visual C++ project files
automatically using a configure script.  I'm not sure how viable it is
at the moment, but I'm certainly willing to do everything necessary to
support you, short of actual testing (I have no MSwin machine).  The
last message I saw about this is at
  http://mail.gnu.org/pipermail/automake/2001-August/009531.html
if you wish to follow it up.

-S


-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants

Re: [Cppunit-devel] 1.6.0 is released!

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

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

> 
> On Mon, Sep 24, 2001 at 09:27:00AM +0200, Bastiaan Bakker wrote:
> 
> > Congratulations on the 1.6.0 release! 
> 
> Thanks to you and to Baptiste!
> 
> > Steve, do you want me to do a FreshMeat announcement? 
> 
> Yes, thanks!
  
  I also posted the news on the XP mailing list 
(ext...@ya..., warning: high traffic).

> 
> 
> On a similar note: does anyone here monitor the source forge web fora
> and answer questions?  Having a long history with usenet and mailing
> lists, I find the web-based messaging exceedingly clumsy, so I don't
> use it.  However, others do use it, and it would be nice for them to
> have their questions answered in a timely fashion.

  I do, but since I have a monthly time budget for internet connection, the 
response are usually off by a few days, if I don't forget completly about them 
(for some strange reason, I can't login on SF anymore from work, I just get 
back to the login page without any error message!).

  I do agree that it is very clumsy in its use: you get a copy of the message, 
but can't answer.

> 
> -S 
> P.S.  I found the first bug in cppunit-docs-1.6.0.tar.gz about 10
> minutes after making it.  The "cookbook.html" file is missing.

  Hey, talking about doc, is there a place where we could put up the WIN32 FAQ 
(got again a FAQ #1 question, and the cockbook will lead to FAQ #1 question 
(crash if RTTI is not enabled)).

  Another point, I'd like to be able to generate documentation with doxygen on 
WIN32. To do so I would need to have a version Doxyfile.in where "macro" stuff 
have been replaced. Is there a way to do that in an automatized fashion ?
 
  Baptiste.

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

RE: [Cppunit-devel] What's NEW?

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

Quoting "Summerwill, Bob" <BSu...@eu...>:

> >> We might also want to include an "expected change" section
> somewhere:
> >> - include directory structure revision
> 
> I've seen this referred to a few times.  What revision is planned to
> the
> include
> directory structure?
> 

  We are refering to an old discussion we had on the list, starting on 
2001/06/14: "include directory clean-up".

  Here are link to the most meaninful messages (I think):

http://www.geocrawler.com/archives/3/6780/2001/6/0/5963093/
http://www.geocrawler.com/archives/3/6780/2001/6/0/5966411/

  Bastiaan did agree that the proposed structure made more sense, but nothing 
conclusive was stated (hey, Steve, have things cleared up since then ?)

  Suggestions are, of course, welcome...

Baptiste.

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

Re: [Cppunit-devel] Unicode Support (was: 1.6.0 is released!)

[Michael A. <ch...@mu...>]

Let me see if I understand you correctly. When not changing anything in =
CppUnit, you are degrading the strings in CppUnit to be simple =
containers which contains "something the TestRunner know what to do =
with" - and currently it just happens to be ASCII strings.

This might work, but I think it should be reflected in the design then - =
f.ex. by letting the TestRunner pass the strings as a pointer to a =
subclass of a specific class (or maybe a template parameter class).

I personnaly do not like a design where a string is something we use to =
stuff  something else into and then decode it again - this way doom =
lies!

You are right __FILE__ are not unicode.

Can you use unicode strings in the assert macros the way you have done =
it?

Yes, unicode use a different runtime library.

A while ago you asked me about Unicode programming on unix. I have found =
an article about unicode on linux: =
http://www-106.ibm.com/developerworks/linux/library/l-linuni.html

I now the first Unicode port for windows I did, was not a very good job. =
I'll be willing to it right, but I need somebody who understands CppUnit =
to talk to about the design.

Enjoy.

    Michael Arnoldus.

----- Original Message -----=20
From: "Baptiste Lepilleur" <gai...@fr...>
To: "Cpp Unit Develpment Mailing List" =
<cpp...@li...>
Sent: Monday, September 24, 2001 1:48 PM
Subject: Re: [Cppunit-devel] Unicode Support (was: 1.6.0 is released!)


> Quoting Michael Arnoldus <ch...@mu...>:
> =20
>=20
> > Unicode support would be nice!
>=20
>   I've been rethinking Unicode support for CppUnit lately. I actually =
wrote the=20
> TestRunner for Qt (which is full Unicode) without having to change =
CppUnit.
>=20
>   It is much easier to move the unicode problem to the TestRunner. The =
only=20
> string that need to be handled at that level are:
>   1) filename (I don't think __FILE__ can handle unicode filename =
anyway)
>   2) failure message (might be a problem if you use ASSERT_EQUAL and =
only work=20
> with non latin1 string).
>=20
>   In most case, it should be possible to get around the problem raised =
by (2).=20
> Though for some applications it might be tough (Japanese to English =
translator=20
> for example). (Note: wouldn't it be possible to encode string using =
MBCS and=20
> decode them later to Unicode ?)
>=20
>   So now the problem would be moved at the TestRunner level, more =
specifically,=20
> the MFC TestRunner.
>   What issue remain ?=20
>   - library: does unicode use a different runtime library (I don't =
remember,=20
> and don't have the unicode version there) ?
>   - adaptability: have the test runner compile with/without unicode =
support and
> convert the string as needed.
>=20
>   What do you think ?
>=20
>   Baptiste.
>=20
> ---
> Baptiste Lepilleur <gai...@fr...>
> http://gaiacrtn.free.fr/index.html
> Language: English, French
>=20
> _______________________________________________
> Cppunit-devel mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cppunit-devel
>=20
>=20
>=20

RE: [Cppunit-devel] include directory change (was: What's NEW?)

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

Quoting "Summerwill, Bob" <BSu...@eu...>:

> >> We might also want to include an "expected change" section
> somewhere:
> >> - include directory structure revision
> 
> I've seen this referred to a few times.  What revision is planned to
> the
> include
> directory structure?

  We are refering to an old discussion we had on the list, starting on 
2001/06/14: "include directory clean-up".

  Here are link to the most meaninful message:

http://www.geocrawler.com/archives/3/6780/2001/6/0/5963093/
http://www.geocrawler.com/archives/3/6780/2001/6/0/5966411/

  Bastiaan did agree that the proposed structure made more sense, but nothing 
conclusive was stated (hey, Steve, have things cleared up since then ?)

  Suggestions are of course welcome...

Baptiste.

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

Re: [Cppunit-devel] Unicode Support (was: 1.6.0 is released!)

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

Quoting Michael Arnoldus <ch...@mu...>:
 

> Unicode support would be nice!

  I've been rethinking Unicode support for CppUnit lately. I actually wrote the 
TestRunner for Qt (which is full Unicode) without having to change CppUnit.

  It is much easier to move the unicode problem to the TestRunner. The only 
string that need to be handled at that level are:
  1) filename (I don't think __FILE__ can handle unicode filename anyway)
  2) failure message (might be a problem if you use ASSERT_EQUAL and only work 
with non latin1 string).

  In most case, it should be possible to get around the problem raised by (2). 
Though for some applications it might be tough (Japanese to English translator 
for example). (Note: wouldn't it be possible to encode string using MBCS and 
decode them later to Unicode ?)

  So now the problem would be moved at the TestRunner level, more specifically, 
the MFC TestRunner.
  What issue remain ? 
  - library: does unicode use a different runtime library (I don't remember, 
and don't have the unicode version there) ?
  - adaptability: have the test runner compile with/without unicode support and
convert the string as needed.

  What do you think ?

  Baptiste.

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

Re: [Cppunit-devel] 1.6.0 is released!

[Steve M. R. <ste...@vi...>]

On Mon, Sep 24, 2001 at 09:27:00AM +0200, Bastiaan Bakker wrote:

> Congratulations on the 1.6.0 release! 

Thanks to you and to Baptiste!

> Steve, do you want me to do a FreshMeat announcement? 

Yes, thanks!


On a similar note: does anyone here monitor the source forge web fora
and answer questions?  Having a long history with usenet and mailing
lists, I find the web-based messaging exceedingly clumsy, so I don't
use it.  However, others do use it, and it would be nice for them to
have their questions answered in a timely fashion.

-S 
P.S.  I found the first bug in cppunit-docs-1.6.0.tar.gz about 10
minutes after making it.  The "cookbook.html" file is missing.

-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants

RE: [Cppunit-devel] What's NEW?

[Summerwill, B. <BSu...@eu...>]

>> We might also want to include an "expected change" section somewhere:
>> - include directory structure revision

I've seen this referred to a few times.  What revision is planned to the
include
directory structure?


Cheers,
Bob





-----Original Message-----
From: Baptiste Lepilleur [mailto:bl...@cl...]
Sent: 23 September 2001 19:59
To: Cpp Unit Develpment Mailing List
Subject: Re: [Cppunit-devel] What's NEW?


----- Original Message -----
From: "Steve M. Robbins" <ste...@vi...>
To: "CppUnit Development" <cpp...@li...>
Sent: Sunday, September 23, 2001 6:50 AM
Subject: [Cppunit-devel] What's NEW?


> I'm working on the final documentation changes for release 1.6.0.  I'm
> going to have a quick sweep through the doxygen docs, then make a new
> (and hopefully final) snapshot before making the release Sunday night.
>
> I'd like to put together a list of the *major* user-visible changes
> (bug fixes and portability enhancements don't count, for example) to
> CppUnit since release 1.5.5.  This list should also answer the
> question "do I have to update any bits of my source code to move from
> 1.5.5 to 1.6.0?"
>

For compatibility related change, I think you covered most of them.

There are also some new functionnality provided by cppunit:
- VC++ integration for MFC TestRunner
- CPPUNIT_ASSERT_MESSAGE( message, expr)
- TestCaller can expect exception
- better setUp()/tearDown() failure support
- better documentation
- INSTALL-WIN32.txt that detail stuff for VC++ platform (project,
compilation and use). Also includes a tiny FAQ with common questions
relating to cppunit/VC++
- More MFC TestRunner examples.

We might also want to include an "expected change" section somewhere:
- include directory structure revision
- namespace for TestRunners
- TestCaller exception support provided with decoration.
- TestFixture
(stuffs we haven't discussed yet but I'd like to change/evolve:
  - Change TestFailure to store a flag indicating if it is an error or a
failure (failed assertion). That would make writing TestRunners a lot
easier.
  - support for 2 differents types in CPPUNIT_ASSERT_EQUAL (I'm kind of fed
up having to cast compatible types when C++ could do that. Make the
assertions harder to read too)
)

> By looking at the ChangeLog, I have generated the following list.  Can
> you help me complete it?  I'm sure that I have left out some stuff
> from the MS side of things.  And did anything change w.r.t. the
> registry?

   What w.r.t. means ?

    The only stuff that relate to the registry is DSPlugIn which is a COM
component and register itself there (it's done at compilation time, and VC++
do it when you add the add-in too I think).

    - VC++ default is now to use type_info. CPPUNIT_DONT_USE_TYPEINFO must
be define if you don't want to use type_info to name suite.

    - A experimental test plug-in runner.

    Notes that the actual implementation of CPPUNIT_TEST_xxx macros have
changed. It use a factory to instiate fixture instead of template methods.


>
> This list will appear in the file NEWS.
>
> Thanks,
> -Steve

    Well, that all I could find/remember.

    May be we should maintain a separate log which would contain change that
impact the user from one version to another ?

Baptiste.


>
>
> New in CppUnit 1.6.0
> --------------------
>
>
> * All CppUnit macros now begin with "CPPUNIT_".
>
>   Macros CU_TEST_SUITE, CU_TEST, CU_TEST_SUITE_END, CU_TEST_SUB_SUITE,
>   and CU_TEST_SUITE_REGISTRATION are renamed but are otherwise unchanged;
>   they take the same arguments, and have the same effect.  A string
replace
>   of CU_ --> CPPUNIT_ will be necessary to update your code.

>
>   Macros assert, assertEqual, and assertDoublesEqual, have been replaced
>   by CPPUNIT_ASSERT, CPPUNIT_ASSERT_EQUAL, and
CPPUNIT_ASSERT_DOUBLES_EQUAL,
>   respectively.  Macro assertLongsEqual is replaced by
CPPUNIT_ASSERT_EQUAL.
>   The old assert macros can be used if your sources #define
>   CPPUNIT_ENABLE_NAKED_ASSERT before including any CppUnit headers.
>
>
> * Equality assertion CPPUNIT_ASSERT_EQUAL(expected,actual) can test
>   any type of expression.  The types of "expected" and "actual" must
>   be the same; use a cast if necessary.
>
>
> * Equality tested using CPPUNIT_ASSERT_EQUAL may be re-defined using
>   a traits class.  Ditto for the string representation used in the
>   diagnostic messages.
>
>
> * CppUnit has a unit test for itself!

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


_______________________________________________
Cppunit-devel mailing list
Cpp...@li...
https://lists.sourceforge.net/lists/listinfo/cppunit-devel

RE: [Cppunit-devel] 1.6.0 is released!

[Summerwill, B. <BSu...@eu...>]

Excellent news!  I'll be grabbing a copy today.


Cheers,
Bob

-----Original Message-----
From: Steve M. Robbins [mailto:ste...@vi...]
Sent: 24 September 2001 05:23
To: CppUnit Development
Subject: [Cppunit-devel] 1.6.0 is released!


I'm happy to report that version 1.6.0 is now available on the
SourceForge web site.

The only significant change from the last snapshot is a last-minute
bugfix from Baptiste.  (The other changes were to doc files.)

The CVS tree is synched up with the release version, and tagged (tag
REL_1_6_0).  My immediate plans are to wait and see what bug reports
come in.  I am prepared to make a 1.6.1 release as soon as necessary,
and generally I plan to keep making 1.6.x releases as necessary to fix
bugs.

In the meanwhile, we should kick around ideas for 1.8.0.  I generally
favour the "release early, release often" policy.  How about the rest
of you?  If we go that route though, we need to be aggressive in
limiting what changes will be made for 1.8.  Let's hear ideas!

-Steve 

P.S.  I haven't yet made a branch in the CVS tree, so let's hold
off on non-bugfix changes until a branch is made.


-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants



_______________________________________________
Cppunit-devel mailing list
Cpp...@li...
https://lists.sourceforge.net/lists/listinfo/cppunit-devel

RE: [Cppunit-devel] 1.6.0 is released!

[Bastiaan B. <Bas...@li...>]

Hi,

Congratulations on the 1.6.0 release!=20
Steve, do you want me to do a FreshMeat announcement?=20

Regards,

Bastiaan
=20

Re: [Cppunit-devel] 1.6.0 is released!

[Michael A. <ch...@mu...>]

Unicode support would be nice!

Enjoy.

    Michael Arnoldus
----- Original Message ----- 
From: "Steve M. Robbins" <ste...@vi...>
To: "CppUnit Development" <cpp...@li...>
Sent: Monday, September 24, 2001 6:23 AM
Subject: [Cppunit-devel] 1.6.0 is released!


> I'm happy to report that version 1.6.0 is now available on the
> SourceForge web site.
> 
> The only significant change from the last snapshot is a last-minute
> bugfix from Baptiste.  (The other changes were to doc files.)
> 
> The CVS tree is synched up with the release version, and tagged (tag
> REL_1_6_0).  My immediate plans are to wait and see what bug reports
> come in.  I am prepared to make a 1.6.1 release as soon as necessary,
> and generally I plan to keep making 1.6.x releases as necessary to fix
> bugs.
> 
> In the meanwhile, we should kick around ideas for 1.8.0.  I generally
> favour the "release early, release often" policy.  How about the rest
> of you?  If we go that route though, we need to be aggressive in
> limiting what changes will be made for 1.8.  Let's hear ideas!
> 
> -Steve 
> 
> P.S.  I haven't yet made a branch in the CVS tree, so let's hold
> off on non-bugfix changes until a branch is made.
> 
> 
> -- 
> by Rocket to the Moon,
> by Airplane to the Rocket,
> by Taxi to the Airport,
> by Frontdoor to the Taxi,
> by throwing back the blanket and laying down the legs ...
> - They Might Be Giants
> 
> 
> 
> _______________________________________________
> Cppunit-devel mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cppunit-devel
> 
> 
> 

[Cppunit-devel] 1.6.0 is released!

[Steve M. R. <ste...@vi...>]

I'm happy to report that version 1.6.0 is now available on the
SourceForge web site.

The only significant change from the last snapshot is a last-minute
bugfix from Baptiste.  (The other changes were to doc files.)

The CVS tree is synched up with the release version, and tagged (tag
REL_1_6_0).  My immediate plans are to wait and see what bug reports
come in.  I am prepared to make a 1.6.1 release as soon as necessary,
and generally I plan to keep making 1.6.x releases as necessary to fix
bugs.

In the meanwhile, we should kick around ideas for 1.8.0.  I generally
favour the "release early, release often" policy.  How about the rest
of you?  If we go that route though, we need to be aggressive in
limiting what changes will be made for 1.8.  Let's hear ideas!

-Steve 

P.S.  I haven't yet made a branch in the CVS tree, so let's hold
off on non-bugfix changes until a branch is made.


-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants

Re: [Cppunit-devel] What's NEW?

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

----- Original Message -----
From: "Steve M. Robbins" <ste...@vi...>
To: "CppUnit Development" <cpp...@li...>
Sent: Sunday, September 23, 2001 6:50 AM
Subject: [Cppunit-devel] What's NEW?


> I'm working on the final documentation changes for release 1.6.0.  I'm
> going to have a quick sweep through the doxygen docs, then make a new
> (and hopefully final) snapshot before making the release Sunday night.
>
> I'd like to put together a list of the *major* user-visible changes
> (bug fixes and portability enhancements don't count, for example) to
> CppUnit since release 1.5.5.  This list should also answer the
> question "do I have to update any bits of my source code to move from
> 1.5.5 to 1.6.0?"
>

For compatibility related change, I think you covered most of them.

There are also some new functionnality provided by cppunit:
- VC++ integration for MFC TestRunner
- CPPUNIT_ASSERT_MESSAGE( message, expr)
- TestCaller can expect exception
- better setUp()/tearDown() failure support
- better documentation
- INSTALL-WIN32.txt that detail stuff for VC++ platform (project,
compilation and use). Also includes a tiny FAQ with common questions
relating to cppunit/VC++
- More MFC TestRunner examples.

We might also want to include an "expected change" section somewhere:
- include directory structure revision
- namespace for TestRunners
- TestCaller exception support provided with decoration.
- TestFixture
(stuffs we haven't discussed yet but I'd like to change/evolve:
  - Change TestFailure to store a flag indicating if it is an error or a
failure (failed assertion). That would make writing TestRunners a lot
easier.
  - support for 2 differents types in CPPUNIT_ASSERT_EQUAL (I'm kind of fed
up having to cast compatible types when C++ could do that. Make the
assertions harder to read too)
)

> By looking at the ChangeLog, I have generated the following list.  Can
> you help me complete it?  I'm sure that I have left out some stuff
> from the MS side of things.  And did anything change w.r.t. the
> registry?

   What w.r.t. means ?

    The only stuff that relate to the registry is DSPlugIn which is a COM
component and register itself there (it's done at compilation time, and VC++
do it when you add the add-in too I think).

    - VC++ default is now to use type_info. CPPUNIT_DONT_USE_TYPEINFO must
be define if you don't want to use type_info to name suite.

    - A experimental test plug-in runner.

    Notes that the actual implementation of CPPUNIT_TEST_xxx macros have
changed. It use a factory to instiate fixture instead of template methods.


>
> This list will appear in the file NEWS.
>
> Thanks,
> -Steve

    Well, that all I could find/remember.

    May be we should maintain a separate log which would contain change that
impact the user from one version to another ?

Baptiste.


>
>
> New in CppUnit 1.6.0
> --------------------
>
>
> * All CppUnit macros now begin with "CPPUNIT_".
>
>   Macros CU_TEST_SUITE, CU_TEST, CU_TEST_SUITE_END, CU_TEST_SUB_SUITE,
>   and CU_TEST_SUITE_REGISTRATION are renamed but are otherwise unchanged;
>   they take the same arguments, and have the same effect.  A string
replace
>   of CU_ --> CPPUNIT_ will be necessary to update your code.

>
>   Macros assert, assertEqual, and assertDoublesEqual, have been replaced
>   by CPPUNIT_ASSERT, CPPUNIT_ASSERT_EQUAL, and
CPPUNIT_ASSERT_DOUBLES_EQUAL,
>   respectively.  Macro assertLongsEqual is replaced by
CPPUNIT_ASSERT_EQUAL.
>   The old assert macros can be used if your sources #define
>   CPPUNIT_ENABLE_NAKED_ASSERT before including any CppUnit headers.
>
>
> * Equality assertion CPPUNIT_ASSERT_EQUAL(expected,actual) can test
>   any type of expression.  The types of "expected" and "actual" must
>   be the same; use a cast if necessary.
>
>
> * Equality tested using CPPUNIT_ASSERT_EQUAL may be re-defined using
>   a traits class.  Ditto for the string representation used in the
>   diagnostic messages.
>
>
> * CppUnit has a unit test for itself!

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

[Cppunit-devel] What's NEW?

[Steve M. R. <ste...@vi...>]

I'm working on the final documentation changes for release 1.6.0.  I'm
going to have a quick sweep through the doxygen docs, then make a new
(and hopefully final) snapshot before making the release Sunday night.

I'd like to put together a list of the *major* user-visible changes
(bug fixes and portability enhancements don't count, for example) to
CppUnit since release 1.5.5.  This list should also answer the
question "do I have to update any bits of my source code to move from
1.5.5 to 1.6.0?"

By looking at the ChangeLog, I have generated the following list.  Can
you help me complete it?  I'm sure that I have left out some stuff
from the MS side of things.  And did anything change w.r.t. the
registry?

This list will appear in the file NEWS.

Thanks,
-Steve


	New in CppUnit 1.6.0
	--------------------


* All CppUnit macros now begin with "CPPUNIT_".  

  Macros CU_TEST_SUITE, CU_TEST, CU_TEST_SUITE_END, CU_TEST_SUB_SUITE,
  and CU_TEST_SUITE_REGISTRATION are renamed but are otherwise unchanged;
  they take the same arguments, and have the same effect.  A string replace
  of CU_ --> CPPUNIT_ will be necessary to update your code.

  Macros assert, assertEqual, and assertDoublesEqual, have been replaced
  by CPPUNIT_ASSERT, CPPUNIT_ASSERT_EQUAL, and CPPUNIT_ASSERT_DOUBLES_EQUAL,
  respectively.  Macro assertLongsEqual is replaced by CPPUNIT_ASSERT_EQUAL.
  The old assert macros can be used if your sources #define
  CPPUNIT_ENABLE_NAKED_ASSERT before including any CppUnit headers.


* Equality assertion CPPUNIT_ASSERT_EQUAL(expected,actual) can test
  any type of expression.  The types of "expected" and "actual" must
  be the same; use a cast if necessary.


* Equality tested using CPPUNIT_ASSERT_EQUAL may be re-defined using
  a traits class.  Ditto for the string representation used in the
  diagnostic messages.


* CppUnit has a unit test for itself!




-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants

[Cppunit-devel] TestRunner for Qt

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

    I wrote a TestRunner using Qt 2.3.0 Non Commercial Edition for windows.

    It still need some works (configure tmake to generate a library,
configure tmake for unix...), but everything is almost there.

    Issue that need to be addressed before we can put this in the CVS tree:
    - where to we put it ? src/qtui/ ? src/qttestruner ?
    - tmake project: need to be modified to generate a library, and need the
"unix" side configuration.
    - tmake for Qt 2.3.0 NCE as some "bugs": it does not generate a makefile
with the right libraries and defines. Mostly solved, but probably break
compilation for owner of the commercial edition.

    You can download the project at:
http://gaiacrtn.free.fr/cppunit/CppUnitQtUi-20010922.zip [155Ko]
    You can see a screen shot at:
http://gaiacrtn.free.fr/cppunit/CppUnitQtUi.JPG

    Enjoy,
    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).

Re: [Cppunit-devel] version 1.6?

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

----- Original Message -----
From: "Steve M. Robbins" <ste...@vi...>
To: "Cpp Unit Develpment Mailing List" <cpp...@li...>
Sent: Friday, September 21, 2001 11:20 PM
Subject: Re: [Cppunit-devel] version 1.6?


> On Fri, Sep 21, 2001 at 12:43:14PM +0200, Baptiste Lepilleur wrote:
> > Quoting "Steve M. Robbins" <ste...@vi...>:
> >
> > > Hello,
> > >
> > > Would anyone get offended if we call the next release "1.6.0", and
> > > move to the convention that version x.y.z comes from the STABLE branch
> > > for even-valued "y", and from the UNSTABLE branch for odd-valued "y" ?
> >
> >   I'm not really familiar with Linux version numbering. Let me check a
few fact:
> >
> > - z is a "patch level": nothing changed in functionnality, but some bug
where
> > fixed.
> > - y is a "functionnality/compatibility level": some functionnality where
added,
> > or some minor compability issues where raised.
> > - x is an "architecture level": major architecture change,
functionnality ?
>
> Yes.  Although there are no hard and fast rules, people generally
> expect the version numbering "x.y.z" to reflect "major", "minor",
> and "micro" differences, as you suggest.
>
> In addition to that, there is the CVS tree.  Since people will
> inevitably use the CVS tree, and submit but reports, we need to be
> able to tell whether the version in question comes from a bona-fide
> release, or from CVS.  I think it is convenient to be able to
> distinguish them based on version number.  That implies that the CVS
> sources would always have a version number attached that is *never* a
> released version.  [Except for a small window of some minutes while a
> release is being prepared.]
>
> It is to support this that I proposed moving to "even = stable",
> "odd = unstable" for the minor version number (or "y", as I called it).
>
> For example, the next release [which I think we can safely make this
> weekend, yes?] will be 1.6.0.  I will check in the sources with
> this version number, and tag it.  Immediately after building the
> tar file, I will update the version to 1.7.0 and commit that to CVS.
    Yes we can do the release. If it come to worth, we can always do a
"micro release".

>
> The CVS head stays in the 1.7 series, leading to a 1.8.0 release.
>
> When we need to make the first bugfix to 1.6, I will create a branch
> rooted at 1.6.0 for the 1.6.x series.
>
> How does that sound?

    This version numbering seems good to me. One of the problem there was
with the bug reports, is that we did not know which version they were
related to.

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

Re: [Cppunit-devel] Snapshot for 2001-09-20

[Steve M. R. <ste...@vi...>]

On Thu, Sep 20, 2001 at 05:34:09PM +0200, Volker Boerchers wrote:
> On Thu, 20 Sep 2001, Steve M. Robbins wrote:
> 
> > Hi,
> > 
> > I made a new snapshot, available at location
> > 
> >   http://www.bic.mni.mcgill.ca/~stever/Software/cppunit-2001-09-20.tar.gz
> > 
> > Changes from yesterday include
> > 
> > * configure script will probe for <strstream>
> > * TestSetupTest restored to CppUnit unit test
> > * tweaking of MS VC++ build
> 
> there seems to be a problem on Linux/gcc version 2.95.2:

Yup.  My fault.

Thanks to Volker for sending his config.log.  I have a new snapshot
up.  Baptiste's latest changes are there, and I re-generated
config/config.h.in.  The configure script should behave better
on unix now.

-Steve



-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants

Re: [Cppunit-devel] version 1.6?

[Steve M. R. <ste...@vi...>]

On Fri, Sep 21, 2001 at 12:43:14PM +0200, Baptiste Lepilleur wrote:
> Quoting "Steve M. Robbins" <ste...@vi...>:
> 
> > Hello,
> > 
> > Would anyone get offended if we call the next release "1.6.0", and
> > move to the convention that version x.y.z comes from the STABLE branch
> > for even-valued "y", and from the UNSTABLE branch for odd-valued "y" ?
> 
>   I'm not really familiar with Linux version numbering. Let me check a few fact:
> 
> - z is a "patch level": nothing changed in functionnality, but some bug where 
> fixed.
> - y is a "functionnality/compatibility level": some functionnality where added, 
> or some minor compability issues where raised.
> - x is an "architecture level": major architecture change, functionnality ?

Yes.  Although there are no hard and fast rules, people generally
expect the version numbering "x.y.z" to reflect "major", "minor",
and "micro" differences, as you suggest.

In addition to that, there is the CVS tree.  Since people will
inevitably use the CVS tree, and submit but reports, we need to be
able to tell whether the version in question comes from a bona-fide
release, or from CVS.  I think it is convenient to be able to
distinguish them based on version number.  That implies that the CVS
sources would always have a version number attached that is *never* a
released version.  [Except for a small window of some minutes while a
release is being prepared.]

It is to support this that I proposed moving to "even = stable",
"odd = unstable" for the minor version number (or "y", as I called it).

For example, the next release [which I think we can safely make this
weekend, yes?] will be 1.6.0.  I will check in the sources with
this version number, and tag it.  Immediately after building the 
tar file, I will update the version to 1.7.0 and commit that to CVS.

The CVS head stays in the 1.7 series, leading to a 1.8.0 release.

When we need to make the first bugfix to 1.6, I will create a branch
rooted at 1.6.0 for the 1.6.x series.

How does that sound?
-S

-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants