cppunit-devel — CppUnit Developer Mailing List

RE: [Cppunit-devel] A few notes about my first experience with cp punit.

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

> -----Oorspronkelijk bericht-----
> Van: Ferdinando Ametrano [mailto:fer...@am...]
> Verzonden: Monday, July 16, 2001 4:01 PM
> Aan: cpp...@li...
> Onderwerp: [Cppunit-devel] A few notes about my first experience with
> cppunit.
> 
> 
> Hi all
> 
> I maintain the QuantLib project (http://quantlib.org). 
> QuantLib is a cross 
> platform (Win32, *nix, Mac) cross compiler (Visual Studio, 
> Borland, gcc, 
> etc.) C++ library for quantitave finance.
> 
> QuantLib is also available as Python extension, and 
> QuantLib-Python has a 
> Python unit test suite. We heavily rely on this suite to test the 
> underlying C++ layer.
> As QuantLib and QuantLib-Python (may) have separate 
> development I would 
> like to add a pure C++ unit test suite.
> 
> A few notes about my first cppunit experience:
> 
> 1) You may consider updating the C++ links at 
> http://www.xprogramming.com/software.htm. This page points to the old 
> versions of cppunit. I toyed with them, and I was going to 
> write to the 
> authors about setting up a sourceforge project.
> I checked the availability of cppunit.sourceforge.net and - 
> bingo! - I 
> found the active project.
> A "c++ unit test" search on google is of no help (except it points to 
> http://sourceforge.net/projects/unittest/)

The CppUnit link must be buried somewhere, because a search with "c++ unit
test sourceforge" does return a link to the CppUnit SF page.
BTW. The CppUnit project on SourceForge isn't affiliated with with
xprogramming.com. I've ask Ron Jeffries (maintainer of xprogramming) to add
a link.

> 
> 2) I opened TestRunner.dsw and I tried to compile the project 
> TestRunner.
> The first errors were because of the inclusion directive
> #include <cppunit/extensions/TestDecorator.h>
> Adding the cppunit/include path to the project didn't help, I 
> had to add it 
> to my VS settings, as if I had installed cppunit (probably 
> because of the <>)
> Then I got linking errors. If I've been naive please help me 
> (I can post 
> the error messages if needed)
> 

Sorry, I can't help you with that, I'm a Unix coder. But there are appear to
be Win32 people on this list as well :-)

> 3) I switched to cygwin for the usual configure-make dance.
> Configure was OK, make failed since cygwin do not recognize 
> my doxygen 
> installation (this is a different problem: cygwin fails to 
> use programs 
> under "Program Files", probably because of the blank space).
> I would humbly suggest to have a different directive for document 
> generation, something like:
> if DOXYGEN_FOUND
> docs:
> 	$(DOXYGEN) Doxyfile.in
> else
> docs:
> 	echo You need to install doxygen in order to generate 
> documentation.
> endif

Hmm, I don't see where things go wrong: if configure cannot detect doxygen
or it has been disabled with '--without-doxygen' the 'doc' subdir will be
excluded from the build, so no attempt to run doxygen will be made. Only if
you explicitly do 'make docs', you'll get an error.

> 
> 4) It would be nice to have a Win32 binary visual installer. 
> This can be 
> easily supported with NSIS 
(http://www.nullsoft.com/free/nsis/). NSIS is 
free and it is script driven. I could help creating the cppunit installer 
script, if somebody help me to select which *.h is needed, etc.

Feel free to to contribute an NSIS script for installation! 

One last question: why there is a separate include and source folder for
msvc6

The separate msvc6 folders are for msvc6 specific code and extensions. If
someone wants to support other Win32 compilers/platforms we may need to
split this into win32 and msvc6, bcb5, etc. subdirs, but there has been no
need for that yet.

These 
In the meantime I'm switching to my Mandrake Linux box ....

I won't argue with that :-)

Regards,

Bastiaan


ciao -- Nando


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

Re: [Cppunit-devel] toString() v.s. getName()

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

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

> On Tue, Jul 10, 2001 at 05:25:51PM +0200, Baptiste Lepilleur wrote:
> 
> >   toString() and getName() have very different semantic.
> > 
> >   * getName(): give me the name of that test so I can identify it.
> > 
> >   * toString(): dump this object as a string so I can diagnose the
> problem (why 
> > is not equal to that other one) without running the debugger.
> > 
> >   So, I would exterminate toString() from CppUnit, with the exception
> of 
> > assertion_traits.
> 
> OK, now I have found one place where the real name of the test is
> required, and not just the "diagnostic string".  In TextTestRunner,
> there are findTestByName() and runTestByName() methods.  Presumably,
> one doesn't want to resort to searching for "footest (suite)".
> 
> Perhaps it is best to retain both getName() and toString().  
  As I said, getName() is used to "identify" the test. Identification is used 
in three ways at the current time:
- reporting which test failed
- look up a test in the tests provided to the TestRunner
- browsing the tests provided to the TestRunner.

toString() make a diagnostic string for an object. Therefore, for TestFailure, 
it dump the test name and the exception message. This implementation of toString
() is not use for reporting test failure and is of no use for CppUnit.

Baptiste.

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

Re: [Cppunit-devel] A few notes about my first experience with cppunit.

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

Hi Ferdinando,

I think all the points you raise are good ones.  I trust that the folks who can
update web pages will do so.  I don't use the windows platform, but I'm sure
that if you can submit patches to implement the ideas you suggest, they will be
considered seriously.

I would suggest that you use the CVS version of CppUnit, and keep abreast of
this mailing list, as the API, such as it is, is very fluid at the moment.


On Mon, Jul 16, 2001 at 04:01:19PM +0200, Ferdinando Ametrano wrote:

> 3) I switched to cygwin for the usual configure-make dance.
> Configure was OK, make failed since cygwin do not recognize my doxygen 
> installation (this is a different problem: cygwin fails to use programs 
> under "Program Files", probably because of the blank space).

When you say "make failed", do you mean that it really stopped with an
error message?  Or do you mean that it failed to generate the documentation?

> I would humbly suggest to have a different directive for document 
> generation, something like:
> if DOXYGEN_FOUND
> docs:
> 	$(DOXYGEN) Doxyfile.in
> else

Something similar to this is done.  Err, maybe only in CVS, though...


-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

[Cppunit-devel] A few notes about my first experience with cppunit.

[Ferdinando A. <fer...@am...>]

Hi all

I maintain the QuantLib project (http://quantlib.org). QuantLib is a cross 
platform (Win32, *nix, Mac) cross compiler (Visual Studio, Borland, gcc, 
etc.) C++ library for quantitave finance.

QuantLib is also available as Python extension, and QuantLib-Python has a 
Python unit test suite. We heavily rely on this suite to test the 
underlying C++ layer.
As QuantLib and QuantLib-Python (may) have separate development I would 
like to add a pure C++ unit test suite.

A few notes about my first cppunit experience:

1) You may consider updating the C++ links at 
http://www.xprogramming.com/software.htm. This page points to the old 
versions of cppunit. I toyed with them, and I was going to write to the 
authors about setting up a sourceforge project.
I checked the availability of cppunit.sourceforge.net and - bingo! - I 
found the active project.
A "c++ unit test" search on google is of no help (except it points to 
http://sourceforge.net/projects/unittest/)

2) I opened TestRunner.dsw and I tried to compile the project TestRunner.
The first errors were because of the inclusion directive
#include <cppunit/extensions/TestDecorator.h>
Adding the cppunit/include path to the project didn't help, I had to add it 
to my VS settings, as if I had installed cppunit (probably because of the <>)
Then I got linking errors. If I've been naive please help me (I can post 
the error messages if needed)

3) I switched to cygwin for the usual configure-make dance.
Configure was OK, make failed since cygwin do not recognize my doxygen 
installation (this is a different problem: cygwin fails to use programs 
under "Program Files", probably because of the blank space).
I would humbly suggest to have a different directive for document 
generation, something like:
if DOXYGEN_FOUND
docs:
	$(DOXYGEN) Doxyfile.in
else
docs:
	echo You need to install doxygen in order to generate documentation.
endif

4) It would be nice to have a Win32 binary visual installer. This can be 
easily supported with NSIS (http://www.nullsoft.com/free/nsis/). NSIS is 
free and it is script driven. I could help creating the cppunit installer 
script, if somebody help me to select which *.h is needed, etc.

One last question: why there is a separate include and source folder for msvc6

In the meantime I'm switching to my Mandrake Linux box ....


ciao -- Nando

Re: [Cppunit-devel] toString() v.s. getName()

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

On Tue, Jul 10, 2001 at 05:25:51PM +0200, Baptiste Lepilleur wrote:

>   toString() and getName() have very different semantic.
> 
>   * getName(): give me the name of that test so I can identify it.
> 
>   * toString(): dump this object as a string so I can diagnose the problem (why 
> is not equal to that other one) without running the debugger.
> 
>   So, I would exterminate toString() from CppUnit, with the exception of 
> assertion_traits.

OK, now I have found one place where the real name of the test is
required, and not just the "diagnostic string".  In TextTestRunner,
there are findTestByName() and runTestByName() methods.  Presumably,
one doesn't want to resort to searching for "footest (suite)".

Perhaps it is best to retain both getName() and toString().  

-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] toString() v.s. getName()

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

On Tue, Jul 10, 2001 at 05:25:51PM +0200, Baptiste Lepilleur wrote:
> Quoting "Steve M. Robbins" <ste...@vi...>:
> 
> > Hi,
> > 
> > With respect to the toString/getName controversy: I realized yesterday
> > that the "assertion_traits" class also has a toString() method.  In
> > this case one is converting an arbitrary type T to a string
> > representation, so "toString()" fits better than "getName()".
> > 
> > I'm starting to wonder whether it is better to eliminate getName()
> > on the Test classes, and stick with toString() universally.  Or,
> > we could go ahead with the initial plan, and leave assertion_traits
> > to be an exception.
> > 
> > I'm leaning towards the first option.
> > Thoughts?
> 
>   toString() and getName() have very different semantic.
> 
>   * getName(): give me the name of that test so I can identify it.
> 
>   * toString(): dump this object as a string so I can diagnose the problem (why 
> is not equal to that other one) without running the debugger.
> 
>   So, I would exterminate toString() from CppUnit, with the exception of 
> assertion_traits.

Mmm.  Upon closer examination still, I find that all the exception
classes *also* have a toString() method.  

I understand that one can make the semantic distinction between
getName() and toString(), as you say.  On the other hand, if a number
of the classes use getName() (roughly, the Test hierarchy), and
another good fraction use toString() (roughly, the test result
classes: assertions and exceptions), folks are likely to be confused.
I, for one, will be unable to keep things straight.

Why not move to "toString()" across the board?

One could say that the semantic of toString() is, as you say, to "dump
the object as a string ... for diagnosis".  The name of a simple test
--- e.g. a TestCase object --- *is* the best textual description of
the object.  For compounds and composed tests, we are not using the
naked name.  TestSuite::toString() returns "suite " + name, and
RepeatedTest::toString() returns name + " (repeated)".  

The diagnostic routines, e.g. TestFailure currently use Test::toString(),
not Test::getName(), so it is the latter that we can safely discard.

-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] class overview I: defining tests

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

----- Original Message -----
From: "Steve M. Robbins" <ste...@vi...>
To: <cpp...@li...>
Sent: Wednesday, July 11, 2001 4:42 PM
Subject: Re: [Cppunit-devel] class overview I: defining tests


> Hi,
>
> Baptiste: thanks for your comments; they are helping clarify the
> CppUnit design in my mind.
>
> Everyone: other comments welcome!
> [...]
> > > class TestCase
> > > --------------
> > >
> > > The concrete class that represents a test should be TestCase.
> > > In fact, however, TestCase is a framework to define one OR MORE tests.
> > > The detailed description of TestCase says it defines the "fixture
> > > to run multiple tests".
> > >
> > > The term "fixture" is bothering me.  The documentation suggests that a
> > > TestCase _is_ a fixture.  If so, why have two terms?  Does the word
> > > "fixture" have a standardized meaning?
> > >
> >  [...]
> >   I'm not sure what "fixture" means in english. The dictionnary did not
provide
> > anything that made sense. The "running" definition I have is that a
fixture
> > provides "context" and "facility" to run a test. I do not know of any
> > standardized meaning, though it's also used in JUnit if I remember well.
>
> OK.  I have not looked at JUnit.  Does anyone know whether JUnit
originated
> the term, or whether it has an antecedent?
>
> I think the term is being used, as you suggest, as a synonym for
"framework",
> except that it is "smaller" than a framework or a sub-part of a framework.
> Something like: "fixture" is to "framework" as "test case" is to "test
suite"?

   I don't really see where it relate to "framework", since the only reuse
there is for a fixture is in the few tests you write using that fixture.
Fixture aren't usally designed for extensibiliy... Oh well, as long as we
know what we are refering to when we are talking about Fixture, it will do.

    That term might be specific to "testing". JUnit introduced a framework,
but the way testing is done is just like the "traditionnal" way with
traditionnal tool (I think): set up a context, run a test....

> > > class TestCaller
> > > ----------------
> > >  [...]
> >   To solve that problem, I would suggest introducing a new base class:
>     [ ... TestFixture ... ]
>
> Yes, I think this would clarify the design.
>
> To reiterate, TestFixture would contain setUp() and tearDown()
> methods.  [You keep using "tearOff", but I assume you really mean
> "tearDown", yes?]  You would subclass this, define void methods, and
> use the latter as a parameter to TestCaller to create test cases.

  Yes, that is exactly what I mean. As you may have already noted, I have
some memory trouble ;-). It is indeed tearDown (one of a reason I use
WorkspaceWhiz to generate my test case, otherwise I would never have them
running!).

> With TestFixture, it seems that TestCase may be defined as
>
> class TestCase : public Test, public TestFixture
>
> and supply implementations of the Test methods, like run().

    I guess so. Hope it doesn't confuse people (TestCaller is a TestCase,
and therefore a TestFixture, and it takes another TestFixture in the
constructor!)

> > Hope this help solve the confusing stuff. (Note that JUnit is even
weirder in
> > that aspect).
>
> Oh dear!  Maybe I *shouldn't* have a look at JUnit after all.  I'm already
> confused enough :-/

    Well, the weird stuff is that the TestCaller is the TestCase itself in
their case. They pass the name of the method to call in the constructor of
TestCase (that why you always need to specify such a constructor). On the
other hand, there are lots of good ideas, probably more documentations.
CppUnit is strongly based on JUnit.

> > [...]
> >   I believe the base TestCase class should remain "test free" (provide
facility
> > to run and report result, but to not do any test). But you rise an
interesting
> > question: should the "exception" expected test be in a TestDecorator
rather
> > than in TestCaller ? This would also make the TestCaller "test free".
>
> Whatever the mechanism, it just seems to me that a test case defined
>
>     1. by subclassing TestCase, or
>     2. by subclassing TestFixture and invoking TestCaller
>
> ought to have the same facilities, including testing for "expected
> exceptions".

    Yes, that why I'd like to remove the "test" from the TestCaller, to keep
it "test free" like the TestCase.

> If you mean to make a new TestDecorator subclass for expecting
> exceptions, akin to the existing RepeatedTest, then yes; to me, that
> sounds like the way to procede.  It has the added virtue of simpler
> code in the common case, when the proposed decorator is NOT used.

    Yes that what I mean. It would also make it much easier to handle
specific case. For example, in many of the TestCases I'm writing, I also
need to check if the exception point out the correct "cause", then I need to
clean up the exception by calling a Destroy method. having a decorator that
could be subclassed would make life much easier.

> > > classes TestDecorator, RepeatedTest, TestSetUp
> > > ----------------------------------------------
> > >
> > > TestDecorator and RepeatedTest are straightforward.
> > >
> > > TestSetUp is a mystery, though.  It appears very similar to
> > > the TestCase class in that it wraps the Test::run() method
> > > with virtual setUp() and tearDown() methods.  But it doesn't
> > > do any catching of exceptions like TestCase does.
> > > What is the purpose of this class?
> >   To use delegation instead of subclassing to set a testing context.
> >
> >   Here is an example of use:
> >   Problem: I need to set a global context each time I run the tests
using the
> > TestRunner. This could be initializing Thread Local Storage to set up
the
> > Database connexion, initializing resource such as COM...
> >   Solution: I provide a way for the user to "wrap" the test being run.
The user
> > could use TestSetUp to do that.
>
> I'm not sure I understand.  Is the set up code to be run once at the
beginning
> of a test run?  Or is it to be run just before each individual test case?
>
> Do you have a real-life example use of TestSetUp that shows why it is
> superior to other means (subclassing?) of achieving the same end?

    Not yet. The example I give is what I plan to add some day to
TestRunner. I need to be able to set up the thread environment (the tests
are running in a separate thead).

    TestSetUp is by no mean superior to subclassing. It just that sometime
you can not subclass (TestRunner does not publish the ActiveTest class). I
haven't find any use (at the current time) for TestSetUp when writing unit
test using TestFixture/TestCaller.

    When you are using TestSetUp, the decorated TestCase become a "Strategy"
for TestSetUp. So the usual Strategy vs Template Method arguments enter in
play here (delegation vs subclassing). I guess it would be interesting to
use TestSetUp if you can reuse your TestSetUp for more than one test (for
example setting up some files, or setting up a thread context).

---
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] class overview I: defining tests

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

Hi,

Baptiste: thanks for your comments; they are helping clarify the
CppUnit design in my mind.

Everyone: other comments welcome!



On Tue, Jul 10, 2001 at 03:24:45PM +0200, Baptiste Lepilleur wrote:
> Quoting "Steve M. Robbins" <ste...@vi...>:
> 
> > 		class Test
> > 		----------
> > 
> > CppUnit has a small hierarchy of classes rooted at class Test.  Test
> > is a pure virtual class with no implementation code.  I will assume it
> > is intended to be an interface class.  By this I mean it exists only
> > to define the interface that a "test-like" classes must implement.  If
> > we were writing Java, it would be an interface.
> 
>   Just to put it out since we haven't yet, Test/TestCase/TestSuite are 
> respectively the Component/Leaf/Composite of a Composite pattern.

Thanks!  That's a useful pointer.


> > The Test interface has one principal method:
> > 
> > 	void run( TestResult* res )
> > 	- run the test and collect the results in res
> 
>   Don't dismiss getName(), it is an essential element of "reporting" result.

True.  While writing, I was in the mind frame of someone who wanted to
understand "how do I write a test case for my code".  The method
getName() should have appeared in part II, but I think I forgot to
mention it there, too.


> > 		class TestCase
> > 		--------------
> > 
> > The concrete class that represents a test should be TestCase.
> > In fact, however, TestCase is a framework to define one OR MORE tests.
> > The detailed description of TestCase says it defines the "fixture
> > to run multiple tests".  
> > 
> > The term "fixture" is bothering me.  The documentation suggests that a
> > TestCase _is_ a fixture.  If so, why have two terms?  Does the word
> > "fixture" have a standardized meaning?
> > 
> > TestCase is a subclass of Test, and implements run() as
> > 
> > 	setUp()
> > 	runTest()
> > 	tearDown()
> > 
> > According to the "cookbook", a TestCase object is intended as the
> > basic mechanism for defining a test.  One should subclass TestCase
> > overriding runTest() appropriately.  The code in runTest() would
> > typically make a number of assertions.  
> 
>   I'm not sure what "fixture" means in english. The dictionnary did not provide 
> anything that made sense. The "running" definition I have is that a fixture 
> provides "context" and "facility" to run a test. I do not know of any 
> standardized meaning, though it's also used in JUnit if I remember well.

OK.  I have not looked at JUnit.  Does anyone know whether JUnit originated
the term, or whether it has an antecedent?

I think the term is being used, as you suggest, as a synonym for "framework",
except that it is "smaller" than a framework or a sub-part of a framework.
Something like: "fixture" is to "framework" as "test case" is to "test suite"?


> > 		class TestCaller
> > 		----------------
> > 
> > Here is where I really start getting muddled.
> > 
> > A TestCaller is a subclass of TestCase that "provides access to a test
> > case method".  Although nowhere clarified in the docs, "a test case
> > method" appears to refer to any member function of a TestCase that
> > takes no parameters and returns void.
> > 
> > All through the TestCaller documentation, the term "fixture" is
> > used to mean "a TestCase instance".
> > 
> > As near as I can tell, a TestCaller exists so that one can subclass a
> > TestCase, define a number of "void foo(void)" methods in it, and then
> > use a TestCaller to make an individual test case out of each such
> > method.
> > 
> > I'm confused now as to whether an object of type TestCase should
> > be a single test case or a set of related test cases.  The name
> > suggests it is a single test case.  However, the TestCaller class
> > appears to promote the practice of defining a set of related tests
> > in a TestCase, and then generating a test case (TestCaller) for each.
>
>   I finally get why you are so confused. Indeed you pointed out a weird stuff 
> in the design.
> 
>   To write a unit test, you basically have two ways:
>   - subclass TestCase, and override the runTest() method to implement your test.
>   - have a class that define a setUp() and a tearOff() methods, and some tests 
> methods. Then create a TestCaller to create a TestCase for each test method.
> 
>   As you can see, TestCaller does not really need a TestCase. As to why 
> TestCase is used, you'll have to go down to the original CppUnit version.
>   The fact are (concerning the use of TestCase to create test suite of 
> TestCaller):
>   - TestCase provides a base class, which define setUp() and tearOff() with 
> empty implementation.
>   - TestCase defines extraneous methods, such as getName(), runTest()...
>   - TestCase is not use as a TestCase.
> 
>   Having a base class is a good thing (At least I think so, it make writing the 
> macros much easier).
>   Having the extraneous methods and a "wrong" use of TestCase is confusing.
> 
>   To solve that problem, I would suggest introducing a new base class:
    [ ... TestFixture ... ]

Yes, I think this would clarify the design.  

To reiterate, TestFixture would contain setUp() and tearDown()
methods.  [You keep using "tearOff", but I assume you really mean
"tearDown", yes?]  You would subclass this, define void methods, and
use the latter as a parameter to TestCaller to create test cases.

With TestFixture, it seems that TestCase may be defined as

	class TestCase : public Test, public TestFixture

and supply implementations of the Test methods, like run().



> Hope this help solve the confusing stuff. (Note that JUnit is even weirder in 
> that aspect).

Oh dear!  Maybe I *shouldn't* have a look at JUnit after all.  I'm already
confused enough :-/


> > In addition, the TestCaller class is able to ignore an "expected"
> > exception in its runTest() method.  This is a useful facility!
> > Why is it not available in the base TestCase class?
> 
>   It is more than "ignoring": if the expected exception is not caught, the test 
> failed. This means that we are implementing a test.

True.  I was being sloppy in my description.


>   I believe the base TestCase class should remain "test free" (provide facility 
> to run and report result, but to not do any test). But you rise an interesting 
> question: should the "exception" expected test be in a TestDecorator rather 
> than in TestCaller ? This would also make the TestCaller "test free".

Whatever the mechanism, it just seems to me that a test case defined

    1. by subclassing TestCase, or
    2. by subclassing TestFixture and invoking TestCaller

ought to have the same facilities, including testing for "expected
exceptions".  

If you mean to make a new TestDecorator subclass for expecting
exceptions, akin to the existing RepeatedTest, then yes; to me, that
sounds like the way to procede.  It has the added virtue of simpler
code in the common case, when the proposed decorator is NOT used.


> > 		classes TestDecorator, RepeatedTest, TestSetUp
> > 		----------------------------------------------
> > 
> > TestDecorator and RepeatedTest are straightforward.
> > 
> > TestSetUp is a mystery, though.  It appears very similar to
> > the TestCase class in that it wraps the Test::run() method
> > with virtual setUp() and tearDown() methods.  But it doesn't 
> > do any catching of exceptions like TestCase does.
> > What is the purpose of this class?
>   To use delegation instead of subclassing to set a testing context.
> 
>   Here is an example of use:
>   Problem: I need to set a global context each time I run the tests using the 
> TestRunner. This could be initializing Thread Local Storage to set up the 
> Database connexion, initializing resource such as COM...
>   Solution: I provide a way for the user to "wrap" the test being run. The user 
> could use TestSetUp to do that.

I'm not sure I understand.  Is the set up code to be run once at the beginning
of a test run?  Or is it to be run just before each individual test case?

Do you have a real-life example use of TestSetUp that shows why it is
superior to other means (subclassing?) of achieving the same end?

-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] toString() v.s. getName()

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

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

> Hi,
> 
> With respect to the toString/getName controversy: I realized yesterday
> that the "assertion_traits" class also has a toString() method.  In
> this case one is converting an arbitrary type T to a string
> representation, so "toString()" fits better than "getName()".
> 
> I'm starting to wonder whether it is better to eliminate getName()
> on the Test classes, and stick with toString() universally.  Or,
> we could go ahead with the initial plan, and leave assertion_traits
> to be an exception.
> 
> I'm leaning towards the first option.
> Thoughts?

  toString() and getName() have very different semantic.

  * getName(): give me the name of that test so I can identify it.

  * toString(): dump this object as a string so I can diagnose the problem (why 
is not equal to that other one) without running the debugger.

  So, I would exterminate toString() from CppUnit, with the exception of 
assertion_traits.

  Baptiste.

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

RE: [Cppunit-devel] Assertions in setUp & tearDown

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

Quoting Pedro Ferreira <ped...@in...>:

> BTW, what are the general guidelines for contributing code back to
> the source tree?

As a patch against the last CVS tree.

Note that if you have some feature you want to add, it would be better to 
discuss them before hand (somebody else might be working on it, or a better 
solution might be found).

Baptiste.


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

Re: [Cppunit-devel] toString() v.s. getName()

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

Hi,

With respect to the toString/getName controversy: I realized yesterday
that the "assertion_traits" class also has a toString() method.  In
this case one is converting an arbitrary type T to a string
representation, so "toString()" fits better than "getName()".

I'm starting to wonder whether it is better to eliminate getName()
on the Test classes, and stick with toString() universally.  Or,
we could go ahead with the initial plan, and leave assertion_traits
to be an exception.

I'm leaning towards the first option.
Thoughts?



On Tue, Jul 10, 2001 at 04:36:57PM +0200, Baptiste Lepilleur wrote:
> Quoting "Steve M. Robbins" <ste...@vi...>:

> > My plan of attack is as follows:
> > 
> > 1. Remove all use of toString() in the library.
> > 2. Document toString() as deprecated in all classes that define it.
> > 3. Replace all toString() implementations with "return getName()".
> > 4. After a respectable number of public releases have been made,
> >    remove all toString() methods.
> > 
> > Optionally, we could replace toString() methods with
> > 
> > 	toString() {
> > 		std::cerr << "Replace toString() with getName()." << endl;
> > 		return getName();
> > 	}
>   (note that this is of no use for Windows user in GUI mode).

Ah.  What happens to the standard streams in GUI mode?  Are they
logged to a file somewhere, simply ignored, or does it cause a
"general protection fault" :-) ?


>   I wouldn't even bother with point (2), (3) and (4). The next release will 
> break so many existing stuffs, and this one is really a minor detail (toString 
> isn't even used by CppUnit).

True, it is a minor detail.  On the other hand, if we maintain backwards
compatibility without too much trouble, I'm willing to do that.


>   Documentation how to do the transition from one version to another should be 
> enough for now (we should start a document for that).

I think that is a good idea.

I have not used any release prior to 1.5.5, so I don't really know
what is being broken or not broken.


-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] toString() v.s. getName()

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

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

> Hi,
> 
> On Wed, Jun 20, 2001 at 08:42:04AM +0200, Baptiste Lepilleur wrote:
> > Conclusion: ditch either toString() or getName(). I find that
> getName() as a
> > more intention revealing name ;-)

> 
> I agree with your conclusion.  And I volunteer to do it (remove
> toString).
> 
> My plan of attack is as follows:
> 
> 1. Remove all use of toString() in the library.
> 2. Document toString() as deprecated in all classes that define it.
> 3. Replace all toString() implementations with "return getName()".
> 4. After a respectable number of public releases have been made,
>    remove all toString() methods.
> 
> Optionally, we could replace toString() methods with
> 
> 	toString() {
> 		std::cerr << "Replace toString() with getName()." << endl;
> 		return getName();
> 	}
  (note that this is of no use for Windows user in GUI mode).
> 
> ... or would that be too obnoxious?  ;-)
  I wouldn't even bother with point (2), (3) and (4). The next release will 
break so many existing stuffs, and this one is really a minor detail (toString 
isn't even used by CppUnit).
  CppUnit status is "pre-alpha", which to me means "might be working some, but 
don't trust it". Seriously, I thing that releasing a list of change since 1.5.5 
is enough. People using CppUnit at pre-alpha stage for serious work should be 
following this list (or they like to live very dangerously).

  So, if someone as problem with toString() methods removal, speak up now ;-)

  Concerning deprecation (no use for now, but might be for later), we could set 
up "compatibility" flag (just like we did for assert). Those flag would be up 
for a few releases before being removed (so you could have the compiler 
locating all the usages of toString() by disabling support for deprecated 
stuff). But I don't think it's worth bothering with deprecation support until 
we reach alpha or beta stage (does somebody have a clear definition of what 
each stage is supposed to be ?). 

  Documentation how to do the transition from one version to another should be 
enough for now (we should start a document for that).

  Baptiste.

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

RE: [Cppunit-devel] Assertions in setUp & tearDown

[Pedro F. <ped...@in...>]

Dear Baptiste,

> > In TestCase::run (TestResult *result):
> > would it be sensible to call setUp and tearDown within the try block
> > or is it deliberate that these methods should not fail?
> 
>   If you look at the current CVS version, it is already done.

I should have looked there beforehand... sorry about that.

> If an exception is thrown during setUp(), a "setup failed" error 
> is reported. 
> The same goes for tearDown().

Great!

BTW, what are the general guidelines for contributing code back to
the source tree?

Thanks to all the CppUnit community for this excellent piece of software!

Pedro

Re: [Cppunit-devel] Assertions in setUp & tearDown

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

Quoting Pedro Ferreira <ped...@in...>:

> Dear all,
> 
> I didn't know whether I should submit this as a bug or as a feature
> request, so here it goes :-)
> 
> In TestCase::run (TestResult *result):
> would it be sensible to call setUp and tearDown within the try block
> or is it deliberate that these methods should not fail?

  If you look at the current CVS version, it is already done.
If an exception is thrown during setUp(), a "setup failed" error is reported. 
The same goes for tearDown().

  Baptiste.
> 
> TIA,
> 
> Pedro
> _____________________________________________________
> Pedro Alves Ferreira
> Project Leader
> INESC Porto                  http://www.inescporto.pt
> Pc da Republica, 93 R/C        Tel: +351 22 209 42 28
> 4050-497 PORTO                 Fax: +351 22 208 41 72
> Portugal          mailto:ped...@in... 
> 
> _______________________________________________
> Cppunit-devel mailing list
> Cpp...@li...
> http://lists.sourceforge.net/lists/listinfo/cppunit-devel
> 



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

Re: [Cppunit-devel] class overview I: defining tests

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

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

> 		class Test
> 		----------
> 
> CppUnit has a small hierarchy of classes rooted at class Test.  Test
> is a pure virtual class with no implementation code.  I will assume it
> is intended to be an interface class.  By this I mean it exists only
> to define the interface that a "test-like" classes must implement.  If
> we were writing Java, it would be an interface.

  Just to put it out since we haven't yet, Test/TestCase/TestSuite are 
respectively the Component/Leaf/Composite of a Composite pattern.

> 
> The Test interface has one principal method:
> 
> 	void run( TestResult* res )
> 	- run the test and collect the results in res

  Don't dismiss getName(), it is an essential element of "reporting" result.

   
> 		class TestCase
> 		--------------
> 
> The concrete class that represents a test should be TestCase.
> In fact, however, TestCase is a framework to define one OR MORE tests.
> The detailed description of TestCase says it defines the "fixture
> to run multiple tests".  
> 
> The term "fixture" is bothering me.  The documentation suggests that a
> TestCase _is_ a fixture.  If so, why have two terms?  Does the word
> "fixture" have a standardized meaning?
> 
> TestCase is a subclass of Test, and implements run() as
> 
> 	setUp()
> 	runTest()
> 	tearDown()
> 
> According to the "cookbook", a TestCase object is intended as the
> basic mechanism for defining a test.  One should subclass TestCase
> overriding runTest() appropriately.  The code in runTest() would
> typically make a number of assertions.  

  I'm not sure what "fixture" means in english. The dictionnary did not provide 
anything that made sense. The "running" definition I have is that a fixture 
provides "context" and "facility" to run a test. I do not know of any 
standardized meaning, though it's also used in JUnit if I remember well.
  I'll continue the discussion about the TestCase/Fixture in TestCaller...


> 		class TestCaller
> 		----------------
> 
> Here is where I really start getting muddled.
> 
> A TestCaller is a subclass of TestCase that "provides access to a test
> case method".  Although nowhere clarified in the docs, "a test case
> method" appears to refer to any member function of a TestCase that
> takes no parameters and returns void.
> 
> All through the TestCaller documentation, the term "fixture" is
> used to mean "a TestCase instance".
> 
> As near as I can tell, a TestCaller exists so that one can subclass a
> TestCase, define a number of "void foo(void)" methods in it, and then
> use a TestCaller to make an individual test case out of each such
> method.
> 
> I'm confused now as to whether an object of type TestCase should
> be a single test case or a set of related test cases.  The name
> suggests it is a single test case.  However, the TestCaller class
> appears to promote the practice of defining a set of related tests
> in a TestCase, and then generating a test case (TestCaller) for each.
  I finally get why you are so confused. Indeed you pointed out a weird stuff 
in the design.

  To write a unit test, you basically have two ways:
  - subclass TestCase, and override the runTest() method to implement your test.
  - have a class that define a setUp() and a tearOff() methods, and some tests 
methods. Then create a TestCaller to create a TestCase for each test method.

  As you can see, TestCaller does not really need a TestCase. As to why 
TestCase is used, you'll have to go down to the original CppUnit version.
  The fact are (concerning the use of TestCase to create test suite of 
TestCaller):
  - TestCase provides a base class, which define setUp() and tearOff() with 
empty implementation.
  - TestCase defines extraneous methods, such as getName(), runTest()...
  - TestCase is not use as a TestCase.

  Having a base class is a good thing (At least I think so, it make writing the 
macros much easier).
  Having the extraneous methods and a "wrong" use of TestCase is confusing.

  To solve that problem, I would suggest introducing a new base class:

/*! This class represents an abstract fixture used to run test with TestCaller.
 *
 * A TestFixture provides a context and facilities to a set of TestCase
 * created with a TestCaller.
 *
 * setUp() is called to initialize the context before running a test, and
 * tearOff() to clean up after running a test.
 */
class TestFixture
{
public:
  virtual ~TestFixture() {}

  virtual void setUp() {}
  virtual void tearOff() {}
};

Well, the definition need work, but the idea is there. The TestFixture is a 
place where you factor out common piece of code of many test case: object 
initialization, comparison...

We would use the TestFixture class, just like we are using the TestCase class 
to define many tests:

class MyTest : public CppUnit::TestFixture
{
  CPPUNIT_TEST_SUITE( MyTest );
  CPPUNIT_TEST( testSomething );
  CPPUNIT_TEST( testSomethingElse );
  CPPUNIT_TEST_SUITE_END();
  
public:
  void setUp();
  void tearOff();

  void testSomething();
  void testSomethingElse();
};

Hope this help solve the confusing stuff. (Note that JUnit is even weirder in 
that aspect).

> 
> In addition, the TestCaller class is able to ignore an "expected"
> exception in its runTest() method.  This is a useful facility!
> Why is it not available in the base TestCase class?

  It is more than "ignoring": if the expected exception is not caught, the test 
failed. This means that we are implementing a test.
  I believe the base TestCase class should remain "test free" (provide facility 
to run and report result, but to not do any test). But you rise an interesting 
question: should the "exception" expected test be in a TestDecorator rather 
than in TestCaller ? This would also make the TestCaller "test free".


> 		classes TestDecorator, RepeatedTest, TestSetUp
> 		----------------------------------------------
> 
> TestDecorator and RepeatedTest are straightforward.
> 
> TestSetUp is a mystery, though.  It appears very similar to
> the TestCase class in that it wraps the Test::run() method
> with virtual setUp() and tearDown() methods.  But it doesn't 
> do any catching of exceptions like TestCase does.
> What is the purpose of this class?
  To use delegation instead of subclassing to set a testing context.

  Here is an example of use:
  Problem: I need to set a global context each time I run the tests using the 
TestRunner. This could be initializing Thread Local Storage to set up the 
Database connexion, initializing resource such as COM...
  Solution: I provide a way for the user to "wrap" the test being run. The user 
could use TestSetUp to do that.

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

[Cppunit-devel] Assertions in setUp & tearDown

[Pedro F. <ped...@in...>]

Dear all,

I didn't know whether I should submit this as a bug or as a feature
request, so here it goes :-)

In TestCase::run (TestResult *result):
would it be sensible to call setUp and tearDown within the try block
or is it deliberate that these methods should not fail?

TIA,

Pedro
_____________________________________________________
Pedro Alves Ferreira
Project Leader
INESC Porto                  http://www.inescporto.pt
Pc da Republica, 93 R/C        Tel: +351 22 209 42 28
4050-497 PORTO                 Fax: +351 22 208 41 72
Portugal          mailto:ped...@in... 

[Cppunit-devel] class overview II: reporting test results

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

This is the second part of my attempt to understand the CppUnit
framework.  I concentrate on classes for running and reporting
test results.



		class TestResult
		----------------

The fundamental run() method of the Test class hierarchy takes a
pointer to a TestResult object.  This TestResult object is responsible
for "collecting the results of executing a test case".

If I may go into Critic Mode for a moment, it seems to me that this
class is responsible for far too many things.  In addition to
collecting test results (i.e. a list of Exceptions and Failures), the
TestResult object also: keeps track of whether some agent (the user?) 
has requested that the tests stop, and keeps a set of TestListeners
and feeds them reports of errors, failures, and tests starting and
stopping.  In addition, the class is cluttered up with synchronization
code.


		class TestListener
		------------------

This class has the clean design that the TestResult ought to have
had.  (IMHO)

I think if I were to design CppUnit from scratch, I'd have Test::run
take a TestListener* parameter instead of TestResult as is currently
done.  From TestListener, I'd make 4 subclasses:

	1. to accumulate errors and failures
	2. to print E/F/. to stdout (c.f. TextTestResult)
	   - you'd also want GUI test listeners to do similar things
	3. to contain a set of listeners, and feed the startTest, addError, 
	   etc callbacks to each in turn (in the spirit of TestSuite)
	4. a TestListener decorator that synchronizes the callbacks
	   to the decorated listener

The functionality of the current TestResult and TextTestResult can be
made from listeners of these four types, with the exception of the
"should I stop?" state (i.e. TestResult's shouldStop() and stop()
methods).

I'm rather tempted to do rework CppUnit in this way.  [See below for
my suggestion on shouldStop().]  Is that too radical?  What if it can
be done keeping backwards compatibility?  How much backwards
compatibility is necessary?


		class TestRunner
		----------------

This class is currently MSVC-only code.  I propose that
CppUnit::TestRunner be reclaimed to the generic portion of the
library.

This class contains a set of tests, and has a run() method.
It should be much like the TestSuite class.  The main difference
is that running the tests will be enclosed in a try block 
that catches a "please stop" exception.  This mechanism
replaces the TestResult methods shouldStop() and stop().

Folks who want a GUI can subclass TestRunner, and use
appropriate TestListeners.

Whaddya think?

-Steve

P.S.  I haven't yet digested the registry and test factory classes.
How do they fit in here?  What can you do with a registry?  Why would
someone want more than one test suite?


-- 
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] class overview I: defining tests

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

In response to Baptiste's message about reorganizing include/, I
expressed a desire to understand the overall structure of CppUnit.  I
have gleaned some information from Baptiste's response and from poring
over the code.  With this summary (in two parts) of what I've learned
so far, I'm hoping to provoke some more discussion.

I'm ignoring the assertions and helper macros, for now.

Suppose I want to incorporate testing into my software.  There are two
fundamental operations that need to be supported by the CppUnit
testing framework.  First, I need to define the tests.  Second, I need
to execute them and report results.  This message deals with classes
of the first category.  A companion message deals with classes for
reporting results.



		class Test
		----------

CppUnit has a small hierarchy of classes rooted at class Test.  Test
is a pure virtual class with no implementation code.  I will assume it
is intended to be an interface class.  By this I mean it exists only
to define the interface that a "test-like" classes must implement.  If
we were writing Java, it would be an interface.

The Test interface has one principal method:

	void run( TestResult* res )
	- run the test and collect the results in res


		class TestCase
		--------------

The concrete class that represents a test should be TestCase.
In fact, however, TestCase is a framework to define one OR MORE tests.
The detailed description of TestCase says it defines the "fixture
to run multiple tests".  

The term "fixture" is bothering me.  The documentation suggests that a
TestCase _is_ a fixture.  If so, why have two terms?  Does the word
"fixture" have a standardized meaning?

TestCase is a subclass of Test, and implements run() as

	setUp()
	runTest()
	tearDown()

According to the "cookbook", a TestCase object is intended as the
basic mechanism for defining a test.  One should subclass TestCase
overriding runTest() appropriately.  The code in runTest() would
typically make a number of assertions.  


		class TestSuite
		---------------

Straightforward collection of Test objects.  The run() method calls
run() on each member of the collection in turn.


		class TestCaller
		----------------

Here is where I really start getting muddled.

A TestCaller is a subclass of TestCase that "provides access to a test
case method".  Although nowhere clarified in the docs, "a test case
method" appears to refer to any member function of a TestCase that
takes no parameters and returns void.

All through the TestCaller documentation, the term "fixture" is
used to mean "a TestCase instance".

As near as I can tell, a TestCaller exists so that one can subclass a
TestCase, define a number of "void foo(void)" methods in it, and then
use a TestCaller to make an individual test case out of each such
method.

I'm confused now as to whether an object of type TestCase should
be a single test case or a set of related test cases.  The name
suggests it is a single test case.  However, the TestCaller class
appears to promote the practice of defining a set of related tests
in a TestCase, and then generating a test case (TestCaller) for each.

In addition, the TestCaller class is able to ignore an "expected"
exception in its runTest() method.  This is a useful facility!
Why is it not available in the base TestCase class?


		classes TestDecorator, RepeatedTest, TestSetUp
		----------------------------------------------

TestDecorator and RepeatedTest are straightforward.

TestSetUp is a mystery, though.  It appears very similar to
the TestCase class in that it wraps the Test::run() method
with virtual setUp() and tearDown() methods.  But it doesn't 
do any catching of exceptions like TestCase does.
What is the purpose of this class?


-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

[Cppunit-devel] toString() v.s. getName()

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

Hi,

On Wed, Jun 20, 2001 at 08:42:04AM +0200, Baptiste Lepilleur wrote:

[ ... while describing the core classes' functionality ... ]

> std::string toString () const:
>   - My best guess would be describes the test. In Java, and Michael
> Feather's original version there is no getName() method, and the toString()
> has the role of the getName() method.
> 
> std::string getName () const:
>   - Identify the test. The returned name should as unique as possible to
> identify the test (that why the TestCase name is included by the
> TestSuiteBuilder). TestRunners rely on that name to run a specified test (or
> suite). Having a name that identify the test without ambiguity help reading
> the failures report (you don't have to bother with the filename).
> 
> Conclusion: ditch either toString() or getName(). I find that getName() as a
> more intention revealing name ;-)

I agree with your conclusion.  And I volunteer to do it (remove toString).

My plan of attack is as follows:

1. Remove all use of toString() in the library.
2. Document toString() as deprecated in all classes that define it.
3. Replace all toString() implementations with "return getName()".
4. After a respectable number of public releases have been made,
   remove all toString() methods.

Optionally, we could replace toString() methods with

	toString() {
		std::cerr << "Replace toString() with getName()." << endl;
		return getName();
	}

... or would that be too obnoxious?  ;-)

Comments?

-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

[Cppunit-devel] examples/cppunittest

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

Hi Baptiste,

I finally got around to looking at the cppunit testsuite again.


On Tue, Jun 12, 2001 at 09:27:15AM +0200, Baptiste Lepilleur wrote:
> ----- Original Message -----
> From: "Steve M. Robbins" <ste...@vi...>
> To: <cpp...@li...>
> Sent: Tuesday, June 12, 2001 12:09 AM
> Subject: Re: [Cppunit-devel] Change done...
> 
> 
> > On Mon, Jun 11, 2001 at 10:25:46PM +0200, Baptiste Lepilleur wrote:
> > > Well, I finally comitted the thing. I checkout the project and it
> compiled
> > > fine, so everything should be there (a lot of files have been added).
> >
> > After some fine-tuning, I got it compiled under unix, with one
> > exception.
> >
> >
> > > You should have exactly 80 unit tests running in cppunittests,
> >
> > I couldn't get examples/cppunit/OrthodoxTest.cpp to compile, and
> > I couldn't figure out how to fix it.  Specifically, I don't understand
> > what is intended by all the "operator !()" functions.  They are
> > declared to return an object of class "Value", but in each case
> > the return statement is computing an integer.

The problem turns out to be simply that two operator== methods were
not declared const.  Now it compiles and runs on linux.


> > After omitting OrthodoxTest, I got 72 tests which all passed.
>     There is one missing. You should have 73 tests.
> 
> With this morning update (NotEqualException/assertEquals), you should have
> (with OrthodoxTest disabled):
> 
> Run:  77   Failures: 1   Errors: 0
> There was 1 failure:
> 1) test: ExceptionTest.testAssignment line: 103
> g:\prg\vc\lib\cppunit\examples\c
> ppunittest\exceptiontest.cpp
> expected: message
> but was:  Unknown exception

When I run it now, I see 83 tests that all succeed.  I get no output
(other than dots).  Is that what you expect?


-- 
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] 2. configure.in queries

[Townsend, G. <gto...@sh...>]

FWIW, I absolutely agree. So much as changed, might as well get something
that will stay fairly stable for some time before the next release.
Especially if it's just a matter of a few days or maybe two weeks.

Guy

> I'd like it if we could to the directory reorganization in the include
> before the 1.5.6. That way we would have something somewhat stable.
> 
> User would already have to do many change to upgrade to 
> 1.5.5. We might as well, get all the "big" change done.

Re: [Cppunit-devel] 2. configure.in queries

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

> Does anyone have showstopper issues for a 1.5.6 release?

Hmm, I still have some clean up to do on the VC++ side.

- A CPPUNIT_TEST_EXPECT_EXCEPTION macro in the work
- can wait but it would be nice to enable the named test suite registration
in this release.

I also like to get done with the test plug in feature (probably this
week-end if I found the time).

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] 2. configure.in queries

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

>
> Does anyone have showstopper issues for a 1.5.6 release?
>

I'd like it if we could to the directory reorganization in the include
before the 1.5.6. That way we would have something somewhat stable.

User would already have to do many change to upgrade to 1.5.5. We might as
well, get all the "big" change done.

Baptiste.

Re: [Cppunit-devel] include directory clean-up

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

In a dsp, you can store many configuration. A configuration is the
equivalent of a makefile (compiler, and link settings).

We have release/debug config. I also added a "crossplatform" config which
disable the typeinfo thingy so I can test if things work fine in that
config.

The macro you found are probably leftover from the change (since we are now
using CPPUNIT_DONT_USE_TYPEINFO to do that).

By the way, you can safely edit files as long as you know what you are doing
(a simple search/replace like this works just fine. It has already been done
when swithing from CU_ to CPPUIT_).

Baptiste.

----- Original Message -----
From: "Steve M. Robbins" <ste...@vi...>
To: <cpp...@li...>
Sent: Friday, July 06, 2001 3:39 AM
Subject: Re: [Cppunit-devel] include directory clean-up


> Hi,
>
> Just a note to say that I checked in the changes to
> replace
> CPPUNIT_USE_TYPEINFO
> with
> CPPUNIT_USE_TYPEINFO_NAME
>
> as we discussed some time back.
>
> I changed all the sources and headers.  I didn't change the .dsp
> files, as they say "DO NOT EDIT".  Should I edit them anyway?
> Should these .dsp files be defining such symbols anyway?  I thought
> the symbols should be defined in the config-xxx.h files?
>
> -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
>
>
> _______________________________________________
> Cppunit-devel mailing list
> Cpp...@li...
> http://lists.sourceforge.net/lists/listinfo/cppunit-devel
>

[Cppunit-devel] CppUnit::OStringStream

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

On Fri, Jul 06, 2001 at 10:05:07AM -0400, Steve M. Robbins wrote:

> I implemented a workaround last night for systems that lack <sstream>,
> based on your suggestion of some weeks ago.  I'd like to commit that
> before the next release.

To elaborate, what I did is define a new class CppUnit::OStringStream
which can be used in the following way.

    CppUnit::OStringStream ost;
    ost << "@Dummy@" << serialNumber++;
    registerFactory( ost.str(), factory );

The definition of OStringStream is the following.  Any comments?


/* Define CPPUNIT_SSTREAM as a stream with a "std::string str()"
 * method.
 */
#include <string>

#if CPPUNIT_HAVE_SSTREAM
#   include <sstream>
    namespace CppUnit {
	typedef std::ostringstream  OStringStream;
    }
#else 
#if CPPUNIT_HAVE_STRSTREAM
#   include <strstream.h>
    namespace CppUnit {
	class OStringStream : public std::ostrstream 
	{
	public:
	    std::string str()
	    {
		(*this) << '\0';                       // necessary?
		std::string msg(ostrstream::str());
		ostrstream::freeze(false); //unfreeze stream [why?]
		return msg;
	    }
	};
    }
#endif
#endif




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