cppunit-devel — CppUnit Developer Mailing List

[Cppunit-devel] Use of decorators esp. TestSetUp

[KLOTZ,PETER (HP-Germany,ex1) <pet...@hp...>]

Hi,

Does anybody have a real-life example of using decorator especially
TestSetUp. E.g. I want to pass command line parameters to a test class or
something else where I need to pass specific context information to a test.
Sure I can subclass TestSetUp and give that sub-class my context
information. But when I want to pass it on to my test class that is wrapped
by the TestSetUp then I kind of need to do a dynamic_cast on m_test
otherwise I cannot call specific methods on the test object and m_Test is of
class TestCase not my special sub-class. 

Isn't there a more general mechanism or some examples how to do this kind of
things? To me it looks like many people must have that problem, or?


Thanks, Peter
---
Peter Klotz 
https://ecardfile.com/id/pklotz

RE: [Cppunit-devel] RE: Auto registration vs. the linker

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

>> The only change is I want to spread it over multiple linking units and it
just doesn't
>> work with Visual C++ as the linker is too smart. 
 
I've run up against this on a number of occasions.  I don't think there is a
solution to it, beyond adding explicit code references.  The code registers
the tests using side-effects, which the linker is unaware of.  I believe
GCC-generated code will suffer from the same problem if it is ee-strip'ed.
I'm sorry I can't provide a better solution.
 
 
Cheers,
Bob
 

-----Original Message-----
From: King Dale [mailto:Ki...@tc...]
Sent: 12 November 2001 16:00
To: 'cpp...@li...'
Subject: [Cppunit-devel] RE: Auto registration vs. the linker



I know I can build it with the executable referencing each subsystem and
then the entry point making references to each subsystem. I'm trying to
avoid this referencing from what would be the root of the tree toward the
bottom of the tree. I'd like to have the leaves of the tree attach
themselves to their parent via the autoregistration. The problem is that you
can't seem to do this when objects are linked from libraries but you can
when it is all in one project.

Why would I want to do this? Well it distributes control rather than
centralized control of tests. It would also allow one to easily enable and
disable tests without editing a source file, you just change the project
dependencies. It also allows multiple build possibilities. In the examples
project you have both a GUI version and a console version of the cppunit
tests. Both projects include all of the source code for the tests. Wouldn't
it make more sense to have one project that defines the tests that is linked
with a text runner project or a gui runner project (which would actually be
generic and not know what they are testing). You just can't seem to do this
however.

And the example do in fact use the linker to do that. Look at the test for
cppunit. You see the file CoreSuite.h that defines the name of the Core
suite. You have tests in the Core suite like TestAssertTest that use that
name and use auto-registration to add themselves to the core suite. There is
nothing in any other source file that even knows of the existence of
TestAssertTest.h or TestAssertTest.cpp. If you moved CoreSuite.h,
TestAssertTest.h and TestAssert.cpp into a separate linking unit, for
example moving all core tests into their own project that builds a static
library to be linked with the main executable you will find that it no
longer works. Not all of the test will get registered. In fact you would
find what I did when attempting something along these lines, that only the
last source file that does the auto registration gets registered!

So you see, what I am trying to do is not that different than what is done
already with cppunit. The only change is I want to spread it over multiple
linking units and it just doesn't work with Visual C++ as the linker is too
smart. The gnu tools have a "whole-archive" option which I think would do
what I want forcing objects in the library to be included even if they are
not referenced. The VC++ linker has a force option but that only forces the
inclusion of a symbol, not of an archive. I could already do that by having
a source file make a reference. There is a pragma to pass options to the
linker from the C source code, so I tried having the actual source file do
the forcing, but it didn't work.

-----Original Message----- 
From: "Baptiste Lepilleur" <bl...@cl...> 
To: <cpp...@li...> 
Subject: Re: [Cppunit-devel] Auto registration vs. the linker 
Date: Sun, 11 Nov 2001 11:14:35 +0100 

You don't use the linker to do that. 

In each "linking unit", you add a entry point that return a suite that 
contains all the unit test of that linking unit. You do that using the 
TestFactoryRegistry (you might want to use addTestToSuite() instead of 
makeTest() so you can name the suite after the "linking unit"). 

In the executable that link against all subsystems, you constructs a suite 
that include all the suite published in the "linking units". You use that 
suite to run the test. 

TestPlugInInterface.h define such an entry point in a standard way, so the 
test can be run on a specific DLL without having to build the executable. 

Baptiste. 

----- Original Message ----- 
From: "King Dale" <Ki...@tc...> 
To: <cpp...@li...> 
Sent: Friday, November 09, 2001 8:35 PM 
Subject: [Cppunit-devel] Auto registration vs. the linker 


> I like and am trying to use auto registration in Visual C++ but the linker

> keeps defeating me. The example cppunit tests work fine because you are 
> building everything as one project. But that is not how I want to do it. 
> This is for a large system and it would work much nicer to have the tests 
> for individual subsystems be built as their own projects and simply link 
> them together with a small runner program within the overall workspace. So

I 
> have a project within the workspace that has the main executable and it 
just 
> gets its test from the registry. I don't want any file within that project

> to know about what tests are out there. Each subsystem is built as a 
shared 
> library that gets linked with the main executable. To add a subsystem to 
the 
> lists of tests you just add its project to the dependencies of the main 
> executable project to get them to link in. 
> 
> The problem is that it will not work as I described it. The linker is too 
> smart. It will not even include any of the object files for the unit tests

> unless they are somehow referenced from the main executable. That is of 
> course what the linker is supposed to do. But I don't want to hardcode 
> references to the tests. This requires extra work to add tests, defeats 
the 
> purpose behind auto registration, and makes it more difficult to change 
the 
> tests you want to run. 
> 
> If you don't use a shared library and build in one project you don't have 
> this problem. The linker includes all .obj files into the output even if 
> they are not referenced, but will not do that if the same .obj files are 
> packaged as a shared library. I don't want to build everything in one 
> project. Different subsytems need different build options and things, so I

> want them to be compiled separately with separate configuration. 
> 
> Does anybody have any way to get the linker to do what I want it to do 
which 
> is to say include all translation units from a shared library whether I 
> reference them or not? 
> 
> -- 
>   Dale King 
> 




--__--__-- 

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


End of Cppunit-devel Digest 

[Cppunit-devel] RE: Auto registration vs. the linker

[King D. <Ki...@tc...>]

I know I can build it with the executable referencing each subsystem and
then the entry point making references to each subsystem. I'm trying to
avoid this referencing from what would be the root of the tree toward the
bottom of the tree. I'd like to have the leaves of the tree attach
themselves to their parent via the autoregistration. The problem is that you
can't seem to do this when objects are linked from libraries but you can
when it is all in one project.

Why would I want to do this? Well it distributes control rather than
centralized control of tests. It would also allow one to easily enable and
disable tests without editing a source file, you just change the project
dependencies. It also allows multiple build possibilities. In the examples
project you have both a GUI version and a console version of the cppunit
tests. Both projects include all of the source code for the tests. Wouldn't
it make more sense to have one project that defines the tests that is linked
with a text runner project or a gui runner project (which would actually be
generic and not know what they are testing). You just can't seem to do this
however.

And the example do in fact use the linker to do that. Look at the test for
cppunit. You see the file CoreSuite.h that defines the name of the Core
suite. You have tests in the Core suite like TestAssertTest that use that
name and use auto-registration to add themselves to the core suite. There is
nothing in any other source file that even knows of the existence of
TestAssertTest.h or TestAssertTest.cpp. If you moved CoreSuite.h,
TestAssertTest.h and TestAssert.cpp into a separate linking unit, for
example moving all core tests into their own project that builds a static
library to be linked with the main executable you will find that it no
longer works. Not all of the test will get registered. In fact you would
find what I did when attempting something along these lines, that only the
last source file that does the auto registration gets registered!

So you see, what I am trying to do is not that different than what is done
already with cppunit. The only change is I want to spread it over multiple
linking units and it just doesn't work with Visual C++ as the linker is too
smart. The gnu tools have a "whole-archive" option which I think would do
what I want forcing objects in the library to be included even if they are
not referenced. The VC++ linker has a force option but that only forces the
inclusion of a symbol, not of an archive. I could already do that by having
a source file make a reference. There is a pragma to pass options to the
linker from the C source code, so I tried having the actual source file do
the forcing, but it didn't work.

-----Original Message-----
From: "Baptiste Lepilleur" <bl...@cl...>
To: <cpp...@li...>
Subject: Re: [Cppunit-devel] Auto registration vs. the linker
Date: Sun, 11 Nov 2001 11:14:35 +0100

You don't use the linker to do that.

In each "linking unit", you add a entry point that return a suite that
contains all the unit test of that linking unit. You do that using the
TestFactoryRegistry (you might want to use addTestToSuite() instead of
makeTest() so you can name the suite after the "linking unit").

In the executable that link against all subsystems, you constructs a suite
that include all the suite published in the "linking units". You use that
suite to run the test.

TestPlugInInterface.h define such an entry point in a standard way, so the
test can be run on a specific DLL without having to build the executable.

Baptiste.

----- Original Message -----
From: "King Dale" <Ki...@tc...>
To: <cpp...@li...>
Sent: Friday, November 09, 2001 8:35 PM
Subject: [Cppunit-devel] Auto registration vs. the linker


> I like and am trying to use auto registration in Visual C++ but the linker
> keeps defeating me. The example cppunit tests work fine because you are
> building everything as one project. But that is not how I want to do it.
> This is for a large system and it would work much nicer to have the tests
> for individual subsystems be built as their own projects and simply link
> them together with a small runner program within the overall workspace. So
I
> have a project within the workspace that has the main executable and it
just
> gets its test from the registry. I don't want any file within that project
> to know about what tests are out there. Each subsystem is built as a
shared
> library that gets linked with the main executable. To add a subsystem to
the
> lists of tests you just add its project to the dependencies of the main
> executable project to get them to link in.
>
> The problem is that it will not work as I described it. The linker is too
> smart. It will not even include any of the object files for the unit tests
> unless they are somehow referenced from the main executable. That is of
> course what the linker is supposed to do. But I don't want to hardcode
> references to the tests. This requires extra work to add tests, defeats
the
> purpose behind auto registration, and makes it more difficult to change
the
> tests you want to run.
>
> If you don't use a shared library and build in one project you don't have
> this problem. The linker includes all .obj files into the output even if
> they are not referenced, but will not do that if the same .obj files are
> packaged as a shared library. I don't want to build everything in one
> project. Different subsytems need different build options and things, so I
> want them to be compiled separately with separate configuration.
>
> Does anybody have any way to get the linker to do what I want it to do
which
> is to say include all translation units from a shared library whether I
> reference them or not?
>
> --
>   Dale King
>




--__--__--

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


End of Cppunit-devel Digest

[Cppunit-devel] CppUnit - TestCase.cpp code addition

[Matt P. <mpa...@op...>]

Hi Guys,
 
Additions we would like to see included in the file 'TestCase.cpp' from the
CppUnit test suite are shown in red below.
 
The additions provide for further feedback when failures occur in the
setUp() and tearDown() routines.
Currently failures in these routines report that the routine itself has
failed.
 
Please use your discretion as to whether the additions should be calls to
'addFailure()' or 'addError()' as necessary.
 
Thanks.
 
Matt Parkinson 
R&D Software Engineer 

Opcom 
PO Box 149 
Toowong QLD 4066 
AUSTRALIA 

Office  +61 07 3371 1311 
Fax     +61 07 3371 1257 
Email   mpa...@op... 
Web     www.opcom.com.au 

 
 
/// Run the test and catch any exceptions that are triggered by it 
void 
TestCase::run (TestResult *result)
{
    result->startTest (this);
 
    try {
 setUp ();
  
 try {
     runTest ();
 }
 catch (Exception& e) {
     Exception *copy = e.clone();
     result->addFailure (this, copy);
 }
 catch (std::exception& e) {
     result->addError (this, new Exception (e.what ()));
 }
 catch (...) {
     Exception *e = new Exception ("caught unknown exception");
     result->addError (this, e);
 }
 
 try {
     tearDown ();
 }
 catch (Exception& e) {
     Exception *copy = e.clone();
     result->addFailure (this, copy);
 }
 catch ( ... ) {
     result->addError( this, new Exception( "tearDown() failed" ) );
 }
    }
 catch (Exception& e) {
     Exception *copy = e.clone();
     result->addFailure (this, copy);
 }
    catch ( ... ) {
 result->addError( this, new Exception( "setUp() failed" ) );
    }
    
    result->endTest (this);
}

Re: [Cppunit-devel] Auto registration vs. the linker

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

You don't use the linker to do that.

In each "linking unit", you add a entry point that return a suite that
contains all the unit test of that linking unit. You do that using the
TestFactoryRegistry (you might want to use addTestToSuite() instead of
makeTest() so you can name the suite after the "linking unit").

In the executable that link against all subsystems, you constructs a suite
that include all the suite published in the "linking units". You use that
suite to run the test.

TestPlugInInterface.h define such an entry point in a standard way, so the
test can be run on a specific DLL without having to build the executable.

Baptiste.

----- Original Message -----
From: "King Dale" <Ki...@tc...>
To: <cpp...@li...>
Sent: Friday, November 09, 2001 8:35 PM
Subject: [Cppunit-devel] Auto registration vs. the linker


> I like and am trying to use auto registration in Visual C++ but the linker
> keeps defeating me. The example cppunit tests work fine because you are
> building everything as one project. But that is not how I want to do it.
> This is for a large system and it would work much nicer to have the tests
> for individual subsystems be built as their own projects and simply link
> them together with a small runner program within the overall workspace. So
I
> have a project within the workspace that has the main executable and it
just
> gets its test from the registry. I don't want any file within that project
> to know about what tests are out there. Each subsystem is built as a
shared
> library that gets linked with the main executable. To add a subsystem to
the
> lists of tests you just add its project to the dependencies of the main
> executable project to get them to link in.
>
> The problem is that it will not work as I described it. The linker is too
> smart. It will not even include any of the object files for the unit tests
> unless they are somehow referenced from the main executable. That is of
> course what the linker is supposed to do. But I don't want to hardcode
> references to the tests. This requires extra work to add tests, defeats
the
> purpose behind auto registration, and makes it more difficult to change
the
> tests you want to run.
>
> If you don't use a shared library and build in one project you don't have
> this problem. The linker includes all .obj files into the output even if
> they are not referenced, but will not do that if the same .obj files are
> packaged as a shared library. I don't want to build everything in one
> project. Different subsytems need different build options and things, so I
> want them to be compiled separately with separate configuration.
>
> Does anybody have any way to get the linker to do what I want it to do
which
> is to say include all translation units from a shared library whether I
> reference them or not?
>
> --
>   Dale King
>

[Cppunit-devel] Auto registration vs. the linker

[King D. <Ki...@tc...>]

I like and am trying to use auto registration in Visual C++ but the linker
keeps defeating me. The example cppunit tests work fine because you are
building everything as one project. But that is not how I want to do it.
This is for a large system and it would work much nicer to have the tests
for individual subsystems be built as their own projects and simply link
them together with a small runner program within the overall workspace. So I
have a project within the workspace that has the main executable and it just
gets its test from the registry. I don't want any file within that project
to know about what tests are out there. Each subsystem is built as a shared
library that gets linked with the main executable. To add a subsystem to the
lists of tests you just add its project to the dependencies of the main
executable project to get them to link in.

The problem is that it will not work as I described it. The linker is too
smart. It will not even include any of the object files for the unit tests
unless they are somehow referenced from the main executable. That is of
course what the linker is supposed to do. But I don't want to hardcode
references to the tests. This requires extra work to add tests, defeats the
purpose behind auto registration, and makes it more difficult to change the
tests you want to run.

If you don't use a shared library and build in one project you don't have
this problem. The linker includes all .obj files into the output even if
they are not referenced, but will not do that if the same .obj files are
packaged as a shared library. I don't want to build everything in one
project. Different subsytems need different build options and things, so I
want them to be compiled separately with separate configuration.

Does anybody have any way to get the linker to do what I want it to do which
is to say include all translation units from a shared library whether I
reference them or not?

-- 
  Dale King

Re: [Cppunit-devel] Test hierarchies?

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

Quoting Stanley Sutton <su...@t-...>:

> Baptiste Lepilleur wrote:
> > 
> > ----- Original Message -----
> > From: "Stanley Sutton" <su...@t-...>
> > 
> > > Is there a way to build test hierachies, other than creating
> seperate
> > > suites?  I ddidn't see an obvous way in the documentation.  For
> example,
> > > I'd like to report all the constructor/destructor tests together,
> > > accessor/mutators together, ...
> > 
> >     No.
> > 
> >     Why do you want to group constructor/destructor tests together ?
> Having
> > per 'component' feedback seems more useful to me, specially when you
> only
> > want to run the test for a specific component...
> > 
> >     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).
> > 
> Mostly because that is the typical way I develop classess. 
> Constructors/Destructors first, then test, then accessor/mutators,
> then
> test, then operators, then test, ...
OK. Still, why do you want to group those together ? To isolate dependency ?

> I'm also looking at changing the code to allow verbose reporting of
> the
> tests for logging purposes, so that each test is listed by name, and
> success/failure is reported.

The XmlOutputter of the current CVS report both sucess and failure.

Baptiste.

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

Re: [Cppunit-devel] Test hierarchies?

[Stanley S. <su...@t-...>]

Baptiste Lepilleur wrote:
> 
> ----- Original Message -----
> From: "Stanley Sutton" <su...@t-...>
> 
> > Is there a way to build test hierachies, other than creating seperate
> > suites?  I ddidn't see an obvous way in the documentation.  For example,
> > I'd like to report all the constructor/destructor tests together,
> > accessor/mutators together, ...
> 
>     No.
> 
>     Why do you want to group constructor/destructor tests together ? Having
> per 'component' feedback seems more useful to me, specially when you only
> want to run the test for a specific component...
> 
>     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).
> 
Mostly because that is the typical way I develop classess. 
Constructors/Destructors first, then test, then accessor/mutators, then
test, then operators, then test, ...

I'm also looking at changing the code to allow verbose reporting of the
tests for logging purposes, so that each test is listed by name, and
success/failure is reported.

-- 
Stanley M. Sutton   sms...@ie...           su...@t-...
TSurf Corporation - The gOcad Company -         http://www.t-surf.com 
11011 Richmond Ave. Suite 350                   Houston TX 77042 
Phone: (1) 713 787 0746 ext. 13                 Fax: (1) 713 787 0852
---------------------------------------------------------------------
They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety.
                                      - Benjamin Franklin

[Cppunit-devel] Distinguishing test case and test suite without relying on RTTI...

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

    Well, this is an issue that have been raised for some time. There is a
simple solution to it: pull more of the Composite pattern into the Test
class.

    I propose to add the following method to the Test class:

    int getChildCount()
    Test *getChildAt( int index )

    => This allow to browse the test hierarchy without relying on RTTI.
    => This allow to create suites which do not subclass TestSuite (you
don't want the suite to assume ownership for example).

    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] Features and future

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

    Well, we're talking about new architecture. Let's also talk about the
feature we want to see in the 'new CppUnit'.

    - distinguishing test case and test suite without relying on RTTI,
    - extending supported base exception type in TestCase::run(): I want
CppUnit to report message of RWXMsg base exception class for exemple,
    - adding 'custom test' to a test suite : I want to add a decorated test,
or add some "standard" test (like Orthodox) to the suite, using the macros,
    - Unicode support in failure message,
    - test suite result tracking : I want to know when a suite start/finish
running, and if it was sucessful.

    I'm probably forgetting some, but that is what I can think of at the
current time. 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).

Re: [Cppunit-devel] CppUnit

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

----- Original Message -----
From: "Pratt, Nick" <np...@mi...>
To: <cpp...@li...>
Sent: Tuesday, October 30, 2001 10:34 PM
Subject: [Cppunit-devel] CppUnit


> Hi
>
> We use CppUnit 1.5 in house for NT unit testing. We made some alterations
to
> it, and I was wondering if you want the diffs in case you wish to add them
> into CppUnit 1.6.x (some of the alterations, you may have already
> added/fixed)
>
> The main ones:
>
> + Renamed assert() to TestAssert() so as not to conflict with <assert.h> -
> nothing major, but it was a pain in the ass.

    CppUnit now use CPPUNIT_ASSERT

> + Production code DLLs are now loaded dynamically, so you dont have to
> relink the HostApp everytime you touch a production code DLL. This
> alteration was not a nice one, but it worked. (You can see for yourself).
Im
> not sure of a nice, cross platform way to do this.

    What do you call 'Product code DLL' ? Is the feature you are refering to
similar to the TestPlugIn feature (still experimental) ?

> + When you shut the HostApp down via the Close button, the MFC "Untitled"
> window no longer pops up.

    This has been solved using a Dialog application instead of an MDI
application and never showing up the dialog. A specific application has been
created to run test plug in (TestPlugInRunner).

> + Added a command line parameter which, if specified, causes only that
> production code DLL to be loaded. Not really an issue with only a few DLLs
> in a directory, but when you have a product with several hundred, loading
up
> HostApp could take a long time.

    I still don't get what you are calling 'Production code DLL'.

> + Fixed some issues that Numega Boundschecker was complaining about in a
> release build.

    Those fixs are welcome.

> Removal of the need to use standard C++ RTTI would be a great benefit
since
> not all platforms/compilers support it, and does add runtime overhead. I
> noticed something in the Changelog about RTTI and some macros, but I need
to
> look into the new docs further to see if you have already done this.

    RTTI is not required, but you won't be able to use the TestRunner if you
don't have it. The TestBrowser rely on RTTI to distinguish TestSuite and
TestCase.

    Baptiste.

Re: [Cppunit-devel] Test hierarchies?

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

----- Original Message -----
From: "Stanley Sutton" <su...@t-...>
To: "CppUnit Developers" <cpp...@li...>
Sent: Monday, October 22, 2001 10:42 PM
Subject: [Cppunit-devel] Test hierarchies?


> Is there a way to build test hierachies, other than creating seperate
> suites?  I ddidn't see an obvous way in the documentation.  For example,
> I'd like to report all the constructor/destructor tests together,
> accessor/mutators together, ...

    No.

    Why do you want to group constructor/destructor tests together ? Having
per 'component' feedback seems more useful to me, specially when you only
want to run the test for a specific component...

    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] [slightly OT] output to dos shell

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

CppUnit 1.7.2 does that without trouble. Test are run as a post-build step
in CppUnitTests example, and error are reported in a VC++ compatible format.

Look up examples/cppunittests/CppUnitTestMain.cpp for details.

Baptiste.

----- Original Message -----
From: "Michael Finney" <mf...@mi...>
To: <cpp...@li...>
Sent: Thursday, October 25, 2001 4:39 PM
Subject: [Cppunit-devel] [slightly OT] output to dos shell


>
> I was trying to output test results to standard output so that the Master
> Build can detect a failure or success; similar to JUnit's test runner.
> However, VC++ 6.0 seems to eat standard-output.  Anything I try to send
out,
> does not show up when I try to launch the application from a command line.
> How can I get some text results to show up when I run the MFC application
> from the command line?
>
> (I am using M. Feather's version of CPPUnit, but I knew there were a lot
of
> people familiar with xUnit and VC++ here.)
>
> Thank you.
> Michael
>
> _______________________________________________
> Cppunit-devel mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cppunit-devel
>

Re: [Cppunit-devel] order of construction, setUp, tearDown and destruction?

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

    Here is what happen during a testing session:

    All test case are created when you call the TestFactoryRegistry method
makeTest Only the constructor of each test case is called. A TestCase is
created for each test method of your test class.

    When you run the test, for each test, the following sequence apply:
    - setUp() is called
    - If setUp() was sucessful (no exception thrown), the test method is
called
    - if setUp() was sucessful, tearDown() is called (even if the test
method failed

    You want to put the call to getTotalObject() in the setUp() method of
your base class.
    And assert for equality in the tearDown() method of your base class.

    Look at TestCase::run(TestResult *result) for more details.

    Baptiste.

----- Original Message -----
From: "Graham, Ted" <Ted...@cs...>
To: <cpp...@li...>
Sent: Thursday, October 25, 2001 12:47 AM
Subject: [Cppunit-devel] order of construction, setUp, tearDown and
destruction?


>
> We are in the process of adopting cppUnit as our automated test framework
> for a large suite of business objects.  Our objects are reference counted,
> so I want to check of how many object are in memory before and after each
> test to make sure that neither the tests nor the code being tested are
> leaking references.
>
> My understanding of a test cases's lifecycle used to be (from a doc I
> wrote):
>    for( testClass = testClass1...testClass99 ) // every test class
>   for( test = test1...test99 ) // every test in that test
> class
>   testClass thisTest; // e.g., CustomerTest
> thisTest
>   testClass.setUp(); // virtual function, can be
> overriden by testClass
>   thisTest.test()
>   testClass.tearDown(); // clean up anything that
> was built in setUp
>   delete testClass; // the test class is
> destroyed after each test.
>
> From debugging the framework, this doesn't seem to be the case.
> Instantiation happens earlier, and tearDown and destruction are delayed
> until after all tests have run.  I have a object BaseTest that inherits
from
> CppUnit::TestCase and is the superclass to all our tests.
>
> Imagine I have a function getTotalObjects() that returns how many
reference
> counted objects are in memory.  I'd like to call this in setUp and again
in
> tearDown and verify that it hasn't changed while the test was being run.
> But I need to know what the lifecycle of test class is, and when setUp and
> tearDown are called.  Any help??
>
> Thanks,
> Ted
>
> _______________________________________________
> Cppunit-devel mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cppunit-devel
>

Re: [Cppunit-devel] A new architecture ?

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

----- Original Message -----
From: "Duane Murphy" <dua...@ma...>
To: "Bastiaan Bakker" <bas...@li...>
Cc: "CppUnit Developers" <cpp...@li...>
Sent: Monday, October 22, 2001 10:23 PM
Subject: Re: [Cppunit-devel] A new architecture ?


> --- At Mon, 22 Oct 2001 22:51:51 +0200, Bastiaan Bakker wrote:
>
> >Duane Murphy wrote:
> >

[...]
> The part that is incorrect is that references can be NULL. A NULL
> reference is illegal. Through programming error you can certainly create
> a NULL reference, but that would be a programming error. ( There was an
> article in CUJ a few months ago in the "Conversations" column by Jim
> Hyslop and Herb Sutter but I cant seem to find an online reference to
> that article.) Pointers on the other hand can legally be NULL.

Some of the rules I inferred from CppUnit source are:
- No public method shall return NULL
- No public method call shall use NULL as a parameter.

If you spot place those rules fail to be respected, let us know and we'll
try to find some work around (likely using NullObject, or exception to
report error).

Baptiste.

---
Baptiste Lepilleur <gai...@fr...>   http://gaiacrtn.free.fr/index.html
Language: English, French (Well, I'm French).

Re: [Cppunit-devel] A new architecture ?

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

----- Original Message -----
From: "Steve M. Robbins" <ste...@vi...>
To: "CppUnit Development Mailing List" <cpp...@li...>
Sent: Monday, October 22, 2001 5:02 AM
Subject: [Cppunit-devel] A new architecture ?

[...]

> Test Construction Classes (CppUnit::Test)
> -----------------------------------------
>
> I'll leave aside the assertions and the exception classes for
> the moment.
>
> The current design includes single test cases and suites of test
> cases, both of which implement a common interface.  As Baptiste
> pointed out these are, respectively, the leaf, composite, and
> component classes of a "Composite Pattern".  I propose to have three
> classes that serve the same purposes, all in CppUnit::Test
> namespace:
>
> Base  - a pure virtual class that defines the interface (i.e. the
Component)
> Case  - the leaf class that implements a *single* test case; subclass of
Base
> Suite - the composite component (also a subclass of Base), consisting
>         of a set of tests where a test could be any subclass of Base
>
> To these basic three -- each of which are fairly simple and clean -- \
> I also added the following.
>
> CaseWithException: a single test that requires that a specified
> exception is thrown.  The class is templated on the exception
> type.

    How does CaseWithException relates to MethodAdpator ?

> FunctionAdaptor: takes a pointer to a "void foo(void)" function
> and turns it into a CppUnit::Test::Case object.

    Why did you add that factory ? Have you found a use for implementing
test case as global function ?

> MethodAdaptor: takes a pointer to a "void foo(void)" class method
> and turns it into a CppUnit::Test::Case object.
>
>
> These three are all subclasses of CppUnit::Test::Case, so very little
> extra code is required.
>
>
> Using the MethodAdaptor and CaseWithException, I can easily implement
> the CPPUNIT_TEST_SUITE(), CPPUNIT_TEST(), CPPUNIT_TEST_EXCEPTION(),
> and CPPUNIT_TEST_SUITE_END() macros.  The beauty of this scheme is

    What happen to CPPUNIT_TEST_SUB_SUITE ?

> that *any* class can contain a test suite.  In the current scheme, I
> think that you can only use these macros in a subclass of
> CppUnit::TestCase.  And with the FunctionAdaptor you can make test
> suites out of arbitrary global functions.

> So the test-definition side seems sufficiently flexible, at least
> to me :-).  Have I missed something out?

    The current macro implementation depends on a common base class to
implement the test hierarchy feature (CPPUNIT_TEST_SUB_SUITE). A factory is
used to instantiate the correct class at each level of the hiearchy (in
registerTests() ). The factory returns a CppUnit::Test * which is the source
of the current dependency to TestCase.

    Beyond adding CaseWithException, I don't see what is different to the
current architecture. Could you point it out ?

    How did you implement the CaseWithException ? I remember trying
implementing CPPUNIT_TEST_EXCEPTION that way (using a test decorator that
expected a specific exception), but it would have been a TestCase decorator,
and it needed to access doRun() on the decorated test case, which is
protected. So I fell back on a template member function added to
TestSuiteBuilder (yuk!)

> Test Result Classes (CppUnit::Result)
> -------------------------------------
>
> To keep the code clean and flexible, I opted here to use the composite
> pattern again.  I used CppUnit::Result::Base for the interface class,
>
> class Base
> {
> public:
>     virtual ~Base() {};
>
>     file://! Callback to indicate a test is about to start.
>     virtual void startTest( CppUnit::Test::Base* test ) = 0;
>
>     file://! Callback to indicate that a failure has occurred.
>     virtual void addFailure( CppUnit::Failure* failure ) = 0;
>
>     file://! Callback to indicate a test has just ended.
>     virtual void endTest( CppUnit::Test::Base* test ) = 0;
> };
>
> and CppUnit::Result::Group for the composite class.  The latter is
> basically identical to the test suite class in that it contains
> a vector of pointers to result classes, and the callbacks are
> passed along to each result object in the group.

    This look goods. Though, why change the class names ? I find that
TestListener more intention revealing...

    Also, I think that the composite should probably be embeded in one of
the CppUnit component. I think that in most cases, you use both a progress
(when the test start to take some time, you want to know if you run into a
infinite loop) and a result (even if only wasSucessful() ).


> What's Next
> -----------
>
> I believe that the current functionality is available using the simple
> classes outlined above.  Those, plus the current assertion functions,
> exception class, and test registry classes.  I haven't looked too
> carefully at the latter, however; perhaps there is room to simplify
> those also.
>
> There are two questions to consider.  First, is it worth reworking the
> foundations of CppUnit?  Certainly, the gain in clarity is persuasive
> to me; how about the rest of you?  Second, if we decide to go ahead
> with this, how much compability must be maintained?

    I beleive we should continue refactoring CppUnit. Beyond clarity, there
is extensibility. By removing the "accumulator" of result test from
TestResult, it is easier to change or extend both the "accumulator" and
TestResult.

    Concerning compatibility, we should consider the part of CppUnit a user
interact with frequently.

    For myself:
    - writing a new test case : helper macros
    - using assertion : CPPUNIT_ASSERT*
    - writing a new assertion : Asserter
    - displaying progress : TestListener
    - printing result : TestResult and misc. outputter

    The helper macros are fairly independent from CppUnit. Change might
concern base class or setUp()/tearDown() though.

    Asserter has been designed to be a facade to CppUnit assertion
implementation, so there should be little impact for user concerning that
class.

    TestListener and TestResult are still the dark ship of the lot, though
your proposed change,  should help reduce impact.

    If you look at the "main" interface of CppUnit, you can see that they
are mainly macro and facade (with the exception of result). Maintaining
compatibility for those should not be too difficult.

[...]
> My initial ambition was to reimplement completely the current Test,
> TestCase, TestCaller, TestResult classes using the new classes.  I
> think that is a lot work and I'm not sure whether the gain is worth
> it.  It is straightforward to replace the TEST_SUITE macros with
> equivalent ones using the new classes.  So any tests that use the
> macros alone will continue to function.  What other techniques are in
> use?  Derivation of TestCase?  Direct use of TestCaller and TestCase
> subclass methods?  How many are worth supporting?

    I once derived TestCase to implement some functionnal tests (creating
TestCase from a file). Should not be of concern (used once compared to
hundred of UT). From experience, using TestCaller directly is a source of
trouble (you have to give the method name twice, and you may run into
portability issue (remember when I forgot to put the '&' before the method
name?)). The only use I can see is if you need to extend the current set of
macros.

    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

[Pratt, N. <np...@mi...>]

Hi
 
We use CppUnit 1.5 in house for NT unit testing. We made some alterations to
it, and I was wondering if you want the diffs in case you wish to add them
into CppUnit 1.6.x (some of the alterations, you may have already
added/fixed)
 
The main ones:
 
+ Renamed assert() to TestAssert() so as not to conflict with <assert.h> -
nothing major, but it was a pain in the ass.
+ Production code DLLs are now loaded dynamically, so you dont have to
relink the HostApp everytime you touch a production code DLL. This
alteration was not a nice one, but it worked. (You can see for yourself). Im
not sure of a nice, cross platform way to do this.
+ When you shut the HostApp down via the Close button, the MFC "Untitled"
window no longer pops up.
+ Added a command line parameter which, if specified, causes only that
production code DLL to be loaded. Not really an issue with only a few DLLs
in a directory, but when you have a product with several hundred, loading up
HostApp could take a long time.
+ Fixed some issues that Numega Boundschecker was complaining about in a
release build.
 
Removal of the need to use standard C++ RTTI would be a great benefit since
not all platforms/compilers support it, and does add runtime overhead. I
noticed something in the Changelog about RTTI and some macros, but I need to
look into the new docs further to see if you have already done this.
 
 
Great idea everyone, Ill be porting our stuff from 1.5 --> 1.6.x today.
 
Nick

[Cppunit-devel] Pointer ownership problems and other thoughts.

[King D. <Ki...@tc...>]

While trying to figure out how to do some things with CppUnit I have come
across a couple problems with pointer ownership.

I tried using the TestRegistry. Unfortunately it assumes ownership of any
tests that are added to it. That makes it virtually unusable. If I get the
tests from the TestRegistry and add them to a runner, then the runner thinks
it owns them as well and you get an access violation on exit. It appears
that this class is not actually intended to be used as it is not even
included in the MSVC++ project. It appears the intent is to have people use
the TestFactoryRegistry instead and perhaps the TestFactory should be
deleted.

I was also looking at TestDecorator. It seems to have the opposite problem,
that it doesn't take ownership of the test it decorates. It seems to me
either it should take ownership or at least have a way to specify whether it
has ownership the way that TestCaller does. Give me garbage collection over
manual memory management any day.

My goal here is to create a macro that goes along with the helper macros to
define a decorated test. Something like this:

    CPPUNIT_TEST_SUITE( MyTest );
    CPPUNIT_TEST( testEquality );
    CPPUNIT_DECORATED_TEST( testSetName, MyTestDecorator );
    CPPUNIT_TEST_SUITE_END();

The only problem I can see here is that this does not allow you to pass any
parameters to the constructor of the test decorator. For instance with
RepeatedTest it does not allow you to set the number of times to repeat. One
solution is to use templates for decorators and the parameters for the
decorator are passed as template parameters so that you would do a repeated
test like:

    CPPUNIT_DECORATED_TEST( testSetName, RepeatedTest< 5 > );

I've kind of been wondering how others set up their tests. Does everybody
use the helper macros or do they define each test as a different class? I
can see some advantages of the latter as you can define hierarchies where
tests that have common setup can use a common base class where that setup is
done. That is not easy to merge with the macro scheme and autoregistration.
The macros are convenient but limiting sometimes.

Re: [Cppunit-devel] 1.6.2 and 1.7.1 on sourceforge

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

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

> Just a note that a new (very minor update) to the stable
> branch was just put on sourceforge.
> 
> In addition, I made a snapshot of the current CVS tree,
> and labelled it version 1.7.1.  You can find it using
> 
>   http://cppunit.sourceforge.net/alpha/
> 
> As the URL indicates, this is an "alpha" release.  Probably it is
> better (what do you think Baptiste?)  to report bugs on this list,
> rather than the formal bug reporting scheme.

  Everything compile fine on Windows for 1.7.1 'pre-'release (with 117 UT 
running).

  Reporting bugs for those pre-release on the list make sense since it provides 
a faster cycle (those pre-release are there mainly to validate that no file is 
missing, and that bug are fixed for those who don't have CVS access). 

  Baptiste.

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

[Cppunit-devel] [slightly OT] output to dos shell

[Michael F. <mf...@mi...>]

I was trying to output test results to standard output so that the Master
Build can detect a failure or success; similar to JUnit's test runner.
However, VC++ 6.0 seems to eat standard-output.  Anything I try to send out,
does not show up when I try to launch the application from a command line.
How can I get some text results to show up when I run the MFC application
from the command line?

(I am using M. Feather's version of CPPUnit, but I knew there were a lot of
people familiar with xUnit and VC++ here.)

Thank you.
Michael

[Cppunit-devel] order of construction, setUp, tearDown and destruction?

[Graham, T. <Ted...@cs...>]

We are in the process of adopting cppUnit as our automated test framework
for a large suite of business objects.  Our objects are reference counted,
so I want to check of how many object are in memory before and after each
test to make sure that neither the tests nor the code being tested are
leaking references.  

My understanding of a test cases's lifecycle used to be (from a doc I
wrote):
   for( testClass = testClass1...testClass99 ) // every test class
 	 	for( test = test1...test99 )	// every test in that test
class
 	 		testClass thisTest;	// e.g., CustomerTest
thisTest
 			testClass.setUp();	// virtual function, can be
overriden by testClass
  	 		thisTest.test()
 			testClass.tearDown();	// clean up anything that
was built in setUp
 	 		delete testClass;		// the test class is
destroyed after each test.
 
From debugging the framework, this doesn't seem to be the case.
Instantiation happens earlier, and tearDown and destruction are delayed
until after all tests have run.  I have a object BaseTest that inherits from
CppUnit::TestCase and is the superclass to all our tests.

Imagine I have a function getTotalObjects() that returns how many reference
counted objects are in memory.  I'd like to call this in setUp and again in
tearDown and verify that it hasn't changed while the test was being run.
But I need to know what the lifecycle of test class is, and when setUp and
tearDown are called.  Any help??

Thanks,
	Ted

Re: [Cppunit-devel] Explanation of ExceptionTest.testAssignment failure under VisualC++

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

Thanks.

I came to similar conclusion a few weeks ago. See
http://www.geocrawler.com/lists/3/SourceForge/6780/0/6778865/ for my
comments on that bug.

Baptiste.

----- Original Message -----
From: "Niel Clausen" <nr...@tr...>
To: <cpp...@li...>
Sent: Monday, October 22, 2001 9:56 AM
Subject: [Cppunit-devel] Explanation of ExceptionTest.testAssignment failure
under VisualC++


> Hi,
> The cause of the failure isn't too hard to figure. To keep the description
> simple, imagine that the vtable for an object is implemented by the _vtbl
> data member. _vtbl points to the class specific vtable, which I'll call
> Class::class_vtbl.
>
> 1. the line "other = e;" causes the other._vtbl to be overwritten with
> exception::class_vtbl.
>
> 2. Hence when "other.what()" is called from within "checkIsSame", the
> routine exception::what() is run, not CppUnit::Exception::what() as
> expected.
>
> The problem seems to lie in the call to the compiler generated assignment
> operator for exception (exception::operator =). Ignoring self assignment,
> this routine first calls exception::~exception (destructor) followed by
the
> compiler generated constructor (I can't tell if this is a default
> constructor or a copy constructor, only the latter really makes sense).
The
> constructor writes this->_vtbl (which of course, it should). In principle,
> this algorithm for generating the assignment operator seems reasonable,
> although not really what I'd expect.
>
> Note that the implementation of CppUnit::Exception::operator = is not
needed
> for this program, as C++ will do the "right thing" when assigning data
> members (it calls each member's assignment operator). Interestingly,
> commenting out CppUnit::Exception::operator = results in the same problem.
> The compiler generated assignment operator for CppUnit::Exception first
> calls exception::operator = (exactly the same as your original
> implementation), and then performs the assignments for each data member.
> Applying the same logic to CppUnit::Exception's copy constructor and
> commenting that out also still gives the same result. For some reason, the
> compiler generated exception::operator = is generated in a fundamentally
> different way to the CppUnit::Exception derived class.
>
> Obviously there's something very odd going on here.
>
>
> best regards,
>
> Niel Clausen.
>
>
>    /\                      Manor Court Yard, High Wycombe
>   /  \    /\  TRANSTECH    Bucks, HP13 5RE, UK
> -/    \  /  \^---------    Voice +44 1494 464432
>        \/     D   S   P    Fax   +44 1494 464472
>
> nr...@tr...        http://www.transtech-dsp.com
>
>
>
> _______________________________________________
> Cppunit-devel mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cppunit-devel
>

[Cppunit-devel] Test hierarchies?

[Stanley S. <su...@t-...>]

Is there a way to build test hierachies, other than creating seperate
suites?  I ddidn't see an obvous way in the documentation.  For example,
I'd like to report all the constructor/destructor tests together,
accessor/mutators together, ...

-- 
Stanley M. Sutton   sms...@ie...           su...@t-...
TSurf Corporation - The gOcad Company -         http://www.t-surf.com 
11011 Richmond Ave. Suite 350                   Houston TX 77042 
Phone: (1) 713 787 0746 ext. 13                 Fax: (1) 713 787 0852
---------------------------------------------------------------------
They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety.
                                      - Benjamin Franklin

Re: [Cppunit-devel] A new architecture ?

[Duane M. <dua...@ma...>]

--- At Mon, 22 Oct 2001 14:23:32 -0700, Duane Murphy wrote:

>There are places for pointers and places for references. If I can use
>references I will. If not I try and use counted pointers. I prefer
>automated memory management to relying on my own poor faculties.
>

I should point out another rule of thumb that I use is that references
should be const and pointers non-const (except for strange things like
const char* :-).

I try and hint at modification. If the paramater is a pointer and it is
non-const likely it will be modified by the function. Clearly const
references are not modifiable parameters. I believe that the standard
also attempts to follow this rule of thumb.

..Duane

p.s.
I am concerned that this will turn into some kind of C++ debate. I was
just bringing up some things that I saw that dont fit the way that I have
learned to do things. We should move forward and focus on CppUnit and
attempt to avoid tangential debates.

My apologies.

Re: [Cppunit-devel] A new architecture ?

[Duane M. <dua...@ma...>]

--- At Mon, 22 Oct 2001 22:51:51 +0200, Bastiaan Bakker wrote:

>Duane Murphy wrote:
>
>>--8<---
>>(3) Use of references. While pointers are evil, references are your
>>friend. Const references are your best friend. They take up minimum
>>space, they have maximum reliability (they cant be NULL), you cant modify
>>
>Hmm, AFAIK references take as much space as pointers. I suspect most 
>compilers translate references and pointers to the same code. They 
>certainly CAN be *NULL (and you'll segfault if you try to use them).
>Personally I find having both pointers and references a not so elegant 
>feature of C++.  But I must confess to have built up a distaste for many 
>C++ 'features' over the years and to prefer the simplicity of Java.

You are absolutely correct, except for one piece. References are
typically implemented in terms of pointers. I have never heard of one
that wasnt but there is nothing that says it couldnt be.

The part that is incorrect is that references can be NULL. A NULL
reference is illegal. Through programming error you can certainly create
a NULL reference, but that would be a programming error. ( There was an
article in CUJ a few months ago in the "Conversations" column by Jim
Hyslop and Herb Sutter but I cant seem to find an online reference to
that article.) Pointers on the other hand can legally be NULL.

There are places for pointers and places for references. If I can use
references I will. If not I try and use counted pointers. I prefer
automated memory management to relying on my own poor faculties.

..Duane