cppunit-devel — CppUnit Developer Mailing List

[Cppunit-devel] CppUnit 1.7.8 tar ball

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

    I finally took the time to go over some patches and features requests.
It is now possible to compile CppUnit as a DLL, and the MFC TestRunner in
Unicode.

    The tar ball are available at the following location:

http://gaiacrtn.free.fr/cppunit/cppunit-1.7.8.tar.gz
http://gaiacrtn.free.fr/cppunit/cppunit-docs-1.7.8.tar.gz

    I need somebody to tell me if thing are OK on the Unix side.

    If no major issue is raised, I think I'll go for a public release (It's
been far too long since the last one).

    Baptiste.
---
Baptiste Lepilleur <gai...@fr...>
http://gaiacrtn.free.fr/

Re: [Cppunit-devel] TestRunner with MFC

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

I usually run the unit test as a post-build step, using the compiler
outputter (just press F4 and you jump right to the failed assertion).

See http://sourceforge.net/forum/message.php?msg_id=1509772 for detail.

Baptiste.

----- Original Message -----
From: "lacall" <la...@mi...>
To: "'Arlo Belshee'" <arl...@ho...>;
<cpp...@li...>
Sent: Monday, March 18, 2002 6:47 PM
Subject: RE: [Cppunit-devel] TestRunner with MFC


> FYI only--I finally got around this problem by avoiding use of TestRunner
> even though it's an MFC app. I use TextTestRunner and redirect the stdout
to
> a file, and display the file. Fast & easy now. Uses a little code I found
> via a google search to redirect stdout in MFC then display it. Thanks for
> the help/info.
>
> Here's what I do now, in case it is useful to anyone:
> #include <cppunit/TextTestRunner.h>
> #include <cppunit/extensions/TestFactoryRegistry.h>
> #include <stdio.h>
> #include <stdlib.h>
> ....
> then in a function called at application startup, when in the app's "test"
> mode:
>
> FILE *stream = freopen( "freopen.out", "w", stdout );
> if( stream == NULL ) {
> AfxMessageBox("error on freopen before trying to run unit tests.");
> } else {
> CppUnit::TextTestRunner runner;
> runner.addTest (
> CppUnit::TestFactoryRegistry::getRegistry().makeTest() );
> runner.run ();
>
> fflush(stream);
> fclose(stream);
> system( "type freopen.out & pause" ); // displays results
> // also possible to redirect back to console (undoing the above; do
> be4 close?):
> // stream = freopen("CON", "w", stdout);
> }
>
> Luke Call
> EDM Group
> Micron Technology, Boise
>
>
> -----Original Message-----
> From: Arlo Belshee [mailto:arl...@ho...]
> Sent: Tuesday, March 12, 2002 2:40 PM
> To: lacall; cpp...@li...
> Subject: RE: [Cppunit-devel] TestRunner with MFC
>
>
> We had this problem. In our case it had a very odd source.
>
> Testrunner.dll (and testrunnerd.dll) were not including their resources
when
> they were built.
>
> We could never firgure out why they built without resources, only that
> sometimes they would have the resources and sometimes they wouldn't. If
they
> didn't, then many lookups would fail, and one of them would finally
assert.
>
> However, I don't know whether you're having the same problem. Thus, here
is
> a list of several other similar-looking problems that I've run into, and
> their solutions.
>
> 1. Threading. CWnds can only be used on the same thread that they are
> created on. As CDialogs are children of CWnds, the same is true of the
> testrunner dialog. Thus, whichever thread causes the creation of the
created
> window (calls Create in the dialog - I don't remember which call on the
test
> runner dialog causes this to happen - run, add test or initial
construction)
> must be the same as thread which calls run (and actually displays the
> dialog). For simplicity, make sure that all interactions with the dialog
> happen from the same thread. This one bit us because we were running tests
> on VMs emulating a distributed network.
>
> 2. MFC dll boundaries suck. If you are using an MFC DLL from a non-MFC
> project, then the dll instance can get easily confused. Make sure that all
> entrypoints into the DLL include the magic macro (AFX_MANAGE_STATE(), or
> something like that). There are other requirements to make a regular DLL
use
> MFC without requiring that the application loading it use MFC, but that's
> the biggie. If you are using this from an application that doesn't use MFC
> (we were running it from a service), then you should probably read MS's
help
> on building regular DLLs that link to MFC, and how they are used.
>
> 2.1. On a related note, make sure that all of yoru test cases also have
the
> correct entry-point behavior. It is very easy to inherit incorrectly or
> include something MFC-dependant and force your entire test to have to
> include the magic macros (especially if you are creating your tests in a
> DLL, and running them from a stub application). Dourblecheck yoru
interfaces
> to make sure that the MFC state is not corrupted.
>
> We've run into a number of other issues as well, but they're not really
> likely. If none of this helps, let me know. I may be able to come up with
> something more.
>
> Arlo
>
> > -----Original Message-----
> > From: cpp...@li...
> >
> > Any other possible ideas or things I should try? I plan on
> > stepping through
> > it in a debugger again to see what I can learn, but spent quite a bit of
> > time on it already. (Thanks for the RTTI idea--it was worth
> > double-checking.)
> >
> > Either way, thanks for a nice product--I hope to get some use out
> > of it and
> > show other members of our group how to use it, once I get this
> > part working.
> >
> > ----- Original Message -----
> > From: "lacall" <la...@mi...>
> >
> > > I'm wondering if someone could point me in the right direction on some
> > kind
> > > of bug in the way I'm using TestRunner. I seem to be using it
> > exactly like
> > > in the example code, and when I call runner.run() it launches the
> > TestRunner
> > > dialog just fine. But when I click the "Browse" button in TestRunner,
I
> > get
> > > a "debug assertion failed" in ...\mfc\src\dlgdata.cpp line 43.
> > It is where
> > > it is calling CDataExchange::PrepareCtrl(...) and the hWinCtrl
> > is null (I
> > > believe it is trying to get the handle to the parent dialog,
> > but it gets a
> > > null value).
> > >
> > > Interestingly, the tests seem to work ok with the TextTestRunner when
> > called
> > > identically from the app. I stepped through it and it worked
> > great (except
> > > that the std::cout test results aren't displayed, due to it being an
MFC
> > > app).
> > >
> > > Any ideas what I may be doing wrong to cause the error with
TestRunner's
> > > Browse button? I have stepped through the code extensively, comparing
it
> > to
> > > the same code and execution path for the provided cppunit MFC
examples,
> > and
> > > can't tell what's different; maybe this particular MFC issue is
> > just over
> > my
> > > head a bit. Many thanks for any ideas!
> > >
> > > Luke Call
> > > EDM Group
> > > Micron Technology, Boise
> > >
> > >
> > > _______________________________________________
> > > Cppunit-devel mailing list
> > > Cpp...@li...
> > > https://lists.sourceforge.net/lists/listinfo/cppunit-devel
> > >
> >
> > _______________________________________________
> > Cppunit-devel mailing list
> > Cpp...@li...
> > https://lists.sourceforge.net/lists/listinfo/cppunit-devel
> >
>
> _______________________________________________
> Cppunit-devel mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cppunit-devel
>

Re: [Cppunit-devel] name of my fixture

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

TestFixture aren't named and don't really need to inherit TestCase (in fact,
a TestFixture class is being introduced, which define only setUp() and
tearDown() ). They're only support class to write unit test. The TestCaller
is the actual TestCase that is added to the TestSuite.

The TestCaller only requires that your fixture define setUp() and
tearDown(), and a default constructor. Therefore you fixture, MoneyTest,
don't need to inherit TestCase. In the current version, you would inherit
TestFixture instead, which defines the required methods.

This doesn't really answer your question but explains why TestFixture aren't
named. Why do you need a different name for ?

Baptiste.

----- Original Message -----
From: "Rachel ANDRE" <rac...@so...>
To: "cppUnit" <cpp...@li...>
Sent: Monday, March 18, 2002 3:16 PM
Subject: [Cppunit-devel] name of my fixture


> Hi,
> I have a little question. I write the classical static suite() method in
my
> test Class (called MoneyTest):
>
> CppUnit::Test * MoneyTest::suite()
> {
> CppUnit::TestSuite *suite = new CppUnit::TestSuite("MoneyTestSuite");
> suite->addTest(new
> CppUnit::TestCaller<MoneyTest>("testGetValue",&MoneyTest::testAdd));
> return suite;
>  }
>
> It works, but the creator of TestCaller calls "MoneyTest()" (constructor
> without parameters) instead of "MoneyTest(std::String name)".
>
> MoneyTest::MoneyTest(std::string nameParam)
> {
> TestCase (nameParam);
> }
> MoneyTest::MoneyTest()
> {
> TestCase ("mewName");
> }
> I don't want to give ever the same name for my fixture ! How can I do ?
>
> Thanks
>
>
>
>
> _______________________________________________
> Cppunit-devel mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cppunit-devel
>

Re: [Cppunit-devel] Signal handling in Linux

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

VC++ provides _set_se_translator() do translate such fault into C++
exception (a life saver when testing multithreaded application). I don't
know if g++ provides a similar functionnality...

Baptiste.

----- Original Message -----
From: "Robert Wenner" <ro...@po...>
To: <cpp...@li...>
Sent: Thursday, March 21, 2002 4:56 PM
Subject: [Cppunit-devel] Signal handling in Linux


Hi,

I expect some of my tests to access a null pointer and thus to raise a
signal (SIGSGV). I would like to thow an Exception on arrival of any
signal to avoid it terminating the program and instead be recorded
as a failed or succeded test run.
The C++ standard does not allow any C++ features being used in
signal handler functions, especially no exceptions.
I really do not like using a global variable (or singleton) which I
check at the end of the test.
Can anybody please point me to a more elegant solution?
Is there perhaps some kind of compiler setting to map signals to
exceptions by default (I use g++)?

Thanks in advance

Robert

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

Re: [Cppunit-devel] a command which automatically add all test methods to a TestSuite

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

    I don't know how everyone use CppUnit, but myself, I use the helper
macros to automatically create and register the TestSuite.

    The advantage is that the only file you need to recompile is the test
you modified. The disavantage being that you can only see what test are in a
suite at runtime (and you may forget adding a test to a suite).

    From what I understood of the source file generated by the Ruby program
(correct me if I'm wrong), all tests are included by the same generated cpp
file and suite are created.

    The advantage is that you can easily see the content of each test suite,
and you can not to forget adding a test to a suite. The disadvantage being
that you must regenerate and recompile that file each time you add a test
(which I think make TFD much more difficult). You also lack the
"flexibility" that the macro bring (expect a test to throw an exception for
example, though much progress can still be done in that area).

    Notes that on the VC++ platform, there is a few command to help create
test case using macro (in the contrib directory).

    I'll gladly welcome any submission you'll make. Even though I see more
disavantage generating the TestSuite hierarchy, it's obviously working well
for many.

    Baptiste.

----- Original Message -----
From: "Hitoshi Katta" <ka...@di...>
To: <cpp...@li...>
Sent: Sunday, March 24, 2002 4:40 PM
Subject: [Cppunit-devel] a command which automatically add all test methods
to a TestSuite


> Why don't you make a command which automatically add all test methods to
> a TestSuite.  In Japan some people use their own Ruby program for this
> purpose.
>
> http://www.diana.dti.ne.jp/~katta/programs/ruby/index_e.html#CppTools
> http://www.s34.co.jp/cpptechdoc/article/cppunit/index.html
> http://oita.cool.ne.jp/ja6hfa/ja6hfa/cppunit/complement_cppunit.html
>
> Regards
>
> KATTA Hitoshi
> ka...@di...

[Cppunit-devel] dialog(plugin)runner & more

[Welti M. <We...@Gr...>]

hi all

i've made some extensions&bugfixes to the dialog(plugin)runner
(well mainly to the pluginrunner)

1)added a label which shows the current running test
2) option to specify the plugin.dll via command line
3) made some fixes so that "reload dll" doesn't crash anymore
4) made the vc++ plugin (go to sourceline) working

anybody interrested in this ? can i merge it somewhere ?

i wonder what the official homepage of cppuni is...
sourceforge has version 1.5.5
freshmeat is at version 1.6.2
in this mailing list, i read a post about version 1.7.3 at
http://gaiacrtn.free.fr/cppunit
regards
marco

-----------------------------------------------
Marco Welti
Software Architect
GretagMacbeth AG
Althardstrasse 70
CH-8105 Regensdorf
Phone: +41 1 842 18 26
Fax: +41 1 842 2860 / 2222
E-Mail: we...@gr...

[Cppunit-devel] a command which automatically add all test methods to a TestSuite

[Hitoshi K. <ka...@di...>]

Why don't you make a command which automatically add all test methods to
a TestSuite.  In Japan some people use their own Ruby program for this
purpose.

http://www.diana.dti.ne.jp/~katta/programs/ruby/index_e.html#CppTools
http://www.s34.co.jp/cpptechdoc/article/cppunit/index.html
http://oita.cool.ne.jp/ja6hfa/ja6hfa/cppunit/complement_cppunit.html

Regards

KATTA Hitoshi
ka...@di...

[Cppunit-devel] Signal handling in Linux

[Robert W. <ro...@po...>]

Hi,

I expect some of my tests to access a null pointer and thus to raise a
signal (SIGSGV). I would like to thow an Exception on arrival of any
signal to avoid it terminating the program and instead be recorded
as a failed or succeded test run.
The C++=A0standard does not allow any C++ features being used in
signal handler functions, especially no exceptions.
I really do not like using a global variable (or singleton) which I=20
check at the end of the test.
Can anybody please point me to a more elegant solution?
Is there perhaps some kind of compiler setting to map signals to
exceptions by default (I use g++)?

Thanks in advance

Robert

RE: [Cppunit-devel] TestRunner with MFC

[lacall <la...@mi...>]

FYI only--I finally got around this problem by avoiding use of TestRunner
even though it's an MFC app. I use TextTestRunner and redirect the stdout to
a file, and display the file. Fast & easy now. Uses a little code I found
via a google search to redirect stdout in MFC then display it. Thanks for
the help/info.

Here's what I do now, in case it is useful to anyone: 
#include <cppunit/TextTestRunner.h>
#include <cppunit/extensions/TestFactoryRegistry.h>
#include <stdio.h>
#include <stdlib.h>
....
then in a function called at application startup, when in the app's "test"
mode:

FILE *stream = freopen( "freopen.out", "w", stdout );
if( stream == NULL ) {
	AfxMessageBox("error on freopen before trying to run unit tests.");
} else {
	CppUnit::TextTestRunner runner;
	runner.addTest (
CppUnit::TestFactoryRegistry::getRegistry().makeTest() );
	runner.run ();

	fflush(stream);
	fclose(stream);
	system( "type freopen.out & pause" ); // displays results
	// also possible to redirect back to console (undoing the above; do
be4 close?):
	//		stream = freopen("CON", "w", stdout); 
}

Luke Call
EDM Group
Micron Technology, Boise


-----Original Message-----
From: Arlo Belshee [mailto:arl...@ho...]
Sent: Tuesday, March 12, 2002 2:40 PM
To: lacall; cpp...@li...
Subject: RE: [Cppunit-devel] TestRunner with MFC


We had this problem. In our case it had a very odd source.

Testrunner.dll (and testrunnerd.dll) were not including their resources when
they were built.

We could never firgure out why they built without resources, only that
sometimes they would have the resources and sometimes they wouldn't. If they
didn't, then many lookups would fail, and one of them would finally assert.

However, I don't know whether you're having the same problem. Thus, here is
a list of several other similar-looking problems that I've run into, and
their solutions.

1. Threading. CWnds can only be used on the same thread that they are
created on. As CDialogs are children of CWnds, the same is true of the
testrunner dialog. Thus, whichever thread causes the creation of the created
window (calls Create in the dialog - I don't remember which call on the test
runner dialog causes this to happen - run, add test or initial construction)
must be the same as thread which calls run (and actually displays the
dialog). For simplicity, make sure that all interactions with the dialog
happen from the same thread. This one bit us because we were running tests
on VMs emulating a distributed network.

2. MFC dll boundaries suck. If you are using an MFC DLL from a non-MFC
project, then the dll instance can get easily confused. Make sure that all
entrypoints into the DLL include the magic macro (AFX_MANAGE_STATE(), or
something like that). There are other requirements to make a regular DLL use
MFC without requiring that the application loading it use MFC, but that's
the biggie. If you are using this from an application that doesn't use MFC
(we were running it from a service), then you should probably read MS's help
on building regular DLLs that link to MFC, and how they are used.

2.1. On a related note, make sure that all of yoru test cases also have the
correct entry-point behavior. It is very easy to inherit incorrectly or
include something MFC-dependant and force your entire test to have to
include the magic macros (especially if you are creating your tests in a
DLL, and running them from a stub application). Dourblecheck yoru interfaces
to make sure that the MFC state is not corrupted.

We've run into a number of other issues as well, but they're not really
likely. If none of this helps, let me know. I may be able to come up with
something more.

Arlo

> -----Original Message-----
> From: cpp...@li...
>
> Any other possible ideas or things I should try? I plan on
> stepping through
> it in a debugger again to see what I can learn, but spent quite a bit of
> time on it already. (Thanks for the RTTI idea--it was worth
> double-checking.)
>
> Either way, thanks for a nice product--I hope to get some use out
> of it and
> show other members of our group how to use it, once I get this
> part working.
>
> ----- Original Message -----
> From: "lacall" <la...@mi...>
>
> > I'm wondering if someone could point me in the right direction on some
> kind
> > of bug in the way I'm using TestRunner. I seem to be using it
> exactly like
> > in the example code, and when I call runner.run() it launches the
> TestRunner
> > dialog just fine. But when I click the "Browse" button in TestRunner, I
> get
> > a "debug assertion failed" in ...\mfc\src\dlgdata.cpp line 43.
> It is where
> > it is calling CDataExchange::PrepareCtrl(...) and the hWinCtrl
> is null (I
> > believe it is trying to get the handle to the parent dialog,
> but it gets a
> > null value).
> >
> > Interestingly, the tests seem to work ok with the TextTestRunner when
> called
> > identically from the app. I stepped through it and it worked
> great (except
> > that the std::cout test results aren't displayed, due to it being an MFC
> > app).
> >
> > Any ideas what I may be doing wrong to cause the error with TestRunner's
> > Browse button? I have stepped through the code extensively, comparing it
> to
> > the same code and execution path for the provided cppunit MFC examples,
> and
> > can't tell what's different; maybe this particular MFC issue is
> just over
> my
> > head a bit. Many thanks for any ideas!
> >
> > Luke Call
> > EDM Group
> > Micron Technology, Boise
> >
> >
> > _______________________________________________
> > Cppunit-devel mailing list
> > Cpp...@li...
> > https://lists.sourceforge.net/lists/listinfo/cppunit-devel
> >
>
> _______________________________________________
> Cppunit-devel mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cppunit-devel
>

[Cppunit-devel] name of my fixture

[Rachel A. <rac...@so...>]

Hi,
I have a little question. I write the classical static suite() method in my
test Class (called MoneyTest):

CppUnit::Test * MoneyTest::suite()
{
CppUnit::TestSuite *suite = new CppUnit::TestSuite("MoneyTestSuite");
suite->addTest(new
CppUnit::TestCaller<MoneyTest>("testGetValue",&MoneyTest::testAdd));
	return suite;
 }

It works, but the creator of TestCaller calls "MoneyTest()" (constructor
without parameters) instead of "MoneyTest(std::String name)".

MoneyTest::MoneyTest(std::string nameParam)
{
		TestCase (nameParam);
}
MoneyTest::MoneyTest()
{
		TestCase ("mewName");
}
I don't want to give ever the same name for my fixture ! How can I do ?

Thanks

[Cppunit-devel] Compiler warnings

[<joh...@es...>]

Hi,

I get the following warnings when compiling at warning level 4 (VC.NET):

d:\Data\common\CppUnit-1.7.3\include\cppunit\Portability.h(50) : warning
C4511: 'CppUnit::OStringStream' : copy constructor could not be generated
        d:\Data\common\CppUnit-1.7.3\include\cppunit\Portability.h(48) : see
declaration of 'CppUnit::OStringStream'
d:\Data\common\CppUnit-1.7.3\include\cppunit\Portability.h(50) : warning
C4512: 'CppUnit::OStringStream' : assignment operator could not be generated
        d:\Data\common\CppUnit-1.7.3\include\cppunit\Portability.h(48) : see
declaration of 'CppUnit::OStringStream'
d:\Data\common\CppUnit-1.7.3\include\cppunit\Exception.h(31) : warning
C4512: 'CppUnit::Exception::Type' : assignment operator could not be
generated
        d:\Data\common\CppUnit-1.7.3\include\cppunit\Exception.h(21) : see
declaration of 'CppUnit::Exception::Type'

Would it be possible to fix these using warning pragmas when compiling under
VC?

// Johan

RE: [Cppunit-devel] TestRunner with MFC

[Arlo B. <arl...@ho...>]

We had this problem. In our case it had a very odd source.

Testrunner.dll (and testrunnerd.dll) were not including their resources when
they were built.

We could never firgure out why they built without resources, only that
sometimes they would have the resources and sometimes they wouldn't. If they
didn't, then many lookups would fail, and one of them would finally assert.

However, I don't know whether you're having the same problem. Thus, here is
a list of several other similar-looking problems that I've run into, and
their solutions.

1. Threading. CWnds can only be used on the same thread that they are
created on. As CDialogs are children of CWnds, the same is true of the
testrunner dialog. Thus, whichever thread causes the creation of the created
window (calls Create in the dialog - I don't remember which call on the test
runner dialog causes this to happen - run, add test or initial construction)
must be the same as thread which calls run (and actually displays the
dialog). For simplicity, make sure that all interactions with the dialog
happen from the same thread. This one bit us because we were running tests
on VMs emulating a distributed network.

2. MFC dll boundaries suck. If you are using an MFC DLL from a non-MFC
project, then the dll instance can get easily confused. Make sure that all
entrypoints into the DLL include the magic macro (AFX_MANAGE_STATE(), or
something like that). There are other requirements to make a regular DLL use
MFC without requiring that the application loading it use MFC, but that's
the biggie. If you are using this from an application that doesn't use MFC
(we were running it from a service), then you should probably read MS's help
on building regular DLLs that link to MFC, and how they are used.

2.1. On a related note, make sure that all of yoru test cases also have the
correct entry-point behavior. It is very easy to inherit incorrectly or
include something MFC-dependant and force your entire test to have to
include the magic macros (especially if you are creating your tests in a
DLL, and running them from a stub application). Dourblecheck yoru interfaces
to make sure that the MFC state is not corrupted.

We've run into a number of other issues as well, but they're not really
likely. If none of this helps, let me know. I may be able to come up with
something more.

Arlo

> -----Original Message-----
> From: cpp...@li...
>
> Any other possible ideas or things I should try? I plan on
> stepping through
> it in a debugger again to see what I can learn, but spent quite a bit of
> time on it already. (Thanks for the RTTI idea--it was worth
> double-checking.)
>
> Either way, thanks for a nice product--I hope to get some use out
> of it and
> show other members of our group how to use it, once I get this
> part working.
>
> ----- Original Message -----
> From: "lacall" <la...@mi...>
>
> > I'm wondering if someone could point me in the right direction on some
> kind
> > of bug in the way I'm using TestRunner. I seem to be using it
> exactly like
> > in the example code, and when I call runner.run() it launches the
> TestRunner
> > dialog just fine. But when I click the "Browse" button in TestRunner, I
> get
> > a "debug assertion failed" in ...\mfc\src\dlgdata.cpp line 43.
> It is where
> > it is calling CDataExchange::PrepareCtrl(...) and the hWinCtrl
> is null (I
> > believe it is trying to get the handle to the parent dialog,
> but it gets a
> > null value).
> >
> > Interestingly, the tests seem to work ok with the TextTestRunner when
> called
> > identically from the app. I stepped through it and it worked
> great (except
> > that the std::cout test results aren't displayed, due to it being an MFC
> > app).
> >
> > Any ideas what I may be doing wrong to cause the error with TestRunner's
> > Browse button? I have stepped through the code extensively, comparing it
> to
> > the same code and execution path for the provided cppunit MFC examples,
> and
> > can't tell what's different; maybe this particular MFC issue is
> just over
> my
> > head a bit. Many thanks for any ideas!
> >
> > Luke Call
> > EDM Group
> > Micron Technology, Boise
> >
> >
> > _______________________________________________
> > Cppunit-devel mailing list
> > Cpp...@li...
> > https://lists.sourceforge.net/lists/listinfo/cppunit-devel
> >
>
> _______________________________________________
> Cppunit-devel mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cppunit-devel
>

RE: [Cppunit-devel] TestRunner with MFC

[lacall <la...@mi...>]

Any other possible ideas or things I should try? I plan on stepping through
it in a debugger again to see what I can learn, but spent quite a bit of
time on it already. (Thanks for the RTTI idea--it was worth
double-checking.)

Either way, thanks for a nice product--I hope to get some use out of it and
show other members of our group how to use it, once I get this part working.

-Luke
-----Original Message-----
From: lacall 
Sent: Monday, March 11, 2002 7:36 AM
To: 'Baptiste Lepilleur'; cpp...@li...
Subject: RE: [Cppunit-devel] TestRunner with MFC


Yes.
-----Original Message-----
From: Baptiste Lepilleur [mailto:gai...@fr...]
Sent: Saturday, March 09, 2002 11:11 AM
To: lacall; cpp...@li...
Subject: Re: [Cppunit-devel] TestRunner with MFC


Are RTTI enabled ?

Baptiste.

----- Original Message -----
From: "lacall" <la...@mi...>
To: <cpp...@li...>
Sent: Saturday, March 09, 2002 3:00 PM
Subject: [Cppunit-devel] TestRunner with MFC


> I'm wondering if someone could point me in the right direction on some
kind
> of bug in the way I'm using TestRunner. I seem to be using it exactly like
> in the example code, and when I call runner.run() it launches the
TestRunner
> dialog just fine. But when I click the "Browse" button in TestRunner, I
get
> a "debug assertion failed" in ...\mfc\src\dlgdata.cpp line 43. It is where
> it is calling CDataExchange::PrepareCtrl(...) and the hWinCtrl is null (I
> believe it is trying to get the handle to the parent dialog, but it gets a
> null value).
>
> Interestingly, the tests seem to work ok with the TextTestRunner when
called
> identically from the app. I stepped through it and it worked great (except
> that the std::cout test results aren't displayed, due to it being an MFC
> app).
>
> Any ideas what I may be doing wrong to cause the error with TestRunner's
> Browse button? I have stepped through the code extensively, comparing it
to
> the same code and execution path for the provided cppunit MFC examples,
and
> can't tell what's different; maybe this particular MFC issue is just over
my
> head a bit. Many thanks for any ideas!
>
> Luke Call
> EDM Group
> Micron Technology, Boise
>
>
> _______________________________________________
> Cppunit-devel mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cppunit-devel
>

RE: [Cppunit-devel] TestRunner with MFC

[lacall <la...@mi...>]

Yes.
-----Original Message-----
From: Baptiste Lepilleur [mailto:gai...@fr...]
Sent: Saturday, March 09, 2002 11:11 AM
To: lacall; cpp...@li...
Subject: Re: [Cppunit-devel] TestRunner with MFC


Are RTTI enabled ?

Baptiste.

----- Original Message -----
From: "lacall" <la...@mi...>
To: <cpp...@li...>
Sent: Saturday, March 09, 2002 3:00 PM
Subject: [Cppunit-devel] TestRunner with MFC


> I'm wondering if someone could point me in the right direction on some
kind
> of bug in the way I'm using TestRunner. I seem to be using it exactly like
> in the example code, and when I call runner.run() it launches the
TestRunner
> dialog just fine. But when I click the "Browse" button in TestRunner, I
get
> a "debug assertion failed" in ...\mfc\src\dlgdata.cpp line 43. It is where
> it is calling CDataExchange::PrepareCtrl(...) and the hWinCtrl is null (I
> believe it is trying to get the handle to the parent dialog, but it gets a
> null value).
>
> Interestingly, the tests seem to work ok with the TextTestRunner when
called
> identically from the app. I stepped through it and it worked great (except
> that the std::cout test results aren't displayed, due to it being an MFC
> app).
>
> Any ideas what I may be doing wrong to cause the error with TestRunner's
> Browse button? I have stepped through the code extensively, comparing it
to
> the same code and execution path for the provided cppunit MFC examples,
and
> can't tell what's different; maybe this particular MFC issue is just over
my
> head a bit. Many thanks for any ideas!
>
> Luke Call
> EDM Group
> Micron Technology, Boise
>
>
> _______________________________________________
> Cppunit-devel mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cppunit-devel
>

[Cppunit-devel] Allow comparison between different types

[<joh...@es...>]

Hi,

just found the need to compare two different data types, e.g.:

CPPUNIT_ASSERT_EQUAL(std::complex(5.0, 0.0), 5.0);

Would it be possible to parameterize the assertion_traits (and accompanying
templates) on both the left and right types, e.g. (from TestAssert.h):

  template <class T, class U = T>
  struct assertion_traits 
  {  
      static bool equal( const T& x, const U& y )
      {
          return x == y;
      }

     template<typename X>
     std::string toString(const X& x) const
     { ... }

 }

... etc ...

Requires modifications to other template declarations in the file as well
(assertEquals), but I've tried making the changes and it compiles, builds
and executes the test suite without failures afterwards (VC++ 7.0).

And, while I'm at it: is there anyone updating the add-in for VC++.NET?

Regards // Johan

Re: [Cppunit-devel] TestRunner with MFC

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

Are RTTI enabled ?

Baptiste.

----- Original Message -----
From: "lacall" <la...@mi...>
To: <cpp...@li...>
Sent: Saturday, March 09, 2002 3:00 PM
Subject: [Cppunit-devel] TestRunner with MFC


> I'm wondering if someone could point me in the right direction on some
kind
> of bug in the way I'm using TestRunner. I seem to be using it exactly like
> in the example code, and when I call runner.run() it launches the
TestRunner
> dialog just fine. But when I click the "Browse" button in TestRunner, I
get
> a "debug assertion failed" in ...\mfc\src\dlgdata.cpp line 43. It is where
> it is calling CDataExchange::PrepareCtrl(...) and the hWinCtrl is null (I
> believe it is trying to get the handle to the parent dialog, but it gets a
> null value).
>
> Interestingly, the tests seem to work ok with the TextTestRunner when
called
> identically from the app. I stepped through it and it worked great (except
> that the std::cout test results aren't displayed, due to it being an MFC
> app).
>
> Any ideas what I may be doing wrong to cause the error with TestRunner's
> Browse button? I have stepped through the code extensively, comparing it
to
> the same code and execution path for the provided cppunit MFC examples,
and
> can't tell what's different; maybe this particular MFC issue is just over
my
> head a bit. Many thanks for any ideas!
>
> Luke Call
> EDM Group
> Micron Technology, Boise
>
>
> _______________________________________________
> Cppunit-devel mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cppunit-devel
>

[Cppunit-devel] TestRunner with MFC

[lacall <la...@mi...>]

I'm wondering if someone could point me in the right direction on some kind
of bug in the way I'm using TestRunner. I seem to be using it exactly like
in the example code, and when I call runner.run() it launches the TestRunner
dialog just fine. But when I click the "Browse" button in TestRunner, I get
a "debug assertion failed" in ...\mfc\src\dlgdata.cpp line 43. It is where
it is calling CDataExchange::PrepareCtrl(...) and the hWinCtrl is null (I
believe it is trying to get the handle to the parent dialog, but it gets a
null value).

Interestingly, the tests seem to work ok with the TextTestRunner when called
identically from the app. I stepped through it and it worked great (except
that the std::cout test results aren't displayed, due to it being an MFC
app).

Any ideas what I may be doing wrong to cause the error with TestRunner's
Browse button? I have stepped through the code extensively, comparing it to
the same code and execution path for the provided cppunit MFC examples, and
can't tell what's different; maybe this particular MFC issue is just over my
head a bit. Many thanks for any ideas!

Luke Call
EDM Group
Micron Technology, Boise

[Cppunit-devel] Graphic environment

[ALTAFULLA,CAROLINA (HP-Spain,ex2) <car...@hp...>]

Hi,

I work for HP and we are successfully using cppunit but we would like =
to
know if any of you are working on the graphical environment for Linux.
We are very interested in improving the functionality of cppunit and I =
am
very interested to know if we can help to build a graphic environment =
for
Linux, like the one in Visual Studio, with some added features.

If any of you are working on it, we could cooperate, otherwise we would =
just
build it and share it with you.

Thanks

Carolina Altafulla
Software Engineer
------------------------------------------------------------------------=
---
R&D Department 				Avda. Graells, 501
Hewlett-Packard 				08190 Sant Cugat del Vall=E8s
(Barcelona)
Inkjet Commercial Division (ICD) 	SPAIN
Telnet #: 712 2258 			Phone #: +34 93 5822258
e-mail: car...@hp... 	Fax #: +34 93 5824816
------------------------------------------------------------------------=
----

[Cppunit-devel] CppUnit 1.7.3 tar ball available

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

    I've made a tar ball of CppUnit 1.7.3.

    You can found it at:
http://gaiacrtn.free.fr/cppunit/cppunit-1.7.3.tar.gz

    Let me know of any issue you run into.

    Baptiste.
---
Baptiste Lepilleur <gai...@fr...>
http://gaiacrtn.free.fr/

[Cppunit-devel] cppunit cvs update, TestResult spit

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

    Well, we discussed a few months ago about the fact that TestResult had
too much responsabilities.

    We had come to a consensus (I believe) that splitting the class along
the responability "collect test result" and "manage the events" would be the
answer to that problem.

    I've done so by extracting the class TestResultCollector, which as you
guessed collect the test result. It is a TestListener that can be registered
to TestResult.

    There should be little impact on application using CppUnit.

    If you had your own classes using TestResult to generate an output, in
most case, replacing it by TestResultCollector should work.

    You can still create a TestResult that behave like the "old" one using
dual inheritance (by subclassing TestResult and TestResultCollector). Look
at TextTestResult for an example of that "trick".

    Also, notes that the signature of the method addFailure() in
TestListener have been changed, and that TextTestRunner::result() returns a
reference instead of a pointer.

    That change had little impact on cppunit (only classes using TestResult
to output the test result where impacted), though it had a wider impact on
cppunit unit testing suites. As a consequence, many of cppunit test cases
have been rewritten/cleaned up.

    For more detail on the change, look up the NEWS file:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/cppunit/cppunit/NE
WS?rev=1.15

    I'll make a tar ball preview as soon as I can.

    Any remarks is welcome,
    Baptiste.

---
Baptiste Lepilleur <gai...@fr...>
http://gaiacrtn.free.fr/

    Baptiste.

Re: [Cppunit-devel] encoding of XmlOutputter @1.7.1-alpha

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

I've added that feature.

Baptiste.
---
Baptiste Lepilleur <gai...@fr...>
http://gaiacrtn.free.fr/

----- Original Message -----
From: "FUKUDA Fumiki" <ff...@nt...>
To: <cpp...@li...>
Sent: Friday, January 18, 2002 2:32 AM
Subject: [Cppunit-devel] encoding of XmlOutputter @1.7.1-alpha


> CppUnit::XmlOutputter prints <?xml...?> at the beginning.
> and it's encoding(charset) is fixed as 'ISO-8859-1'
> however assertion message is NOT always English
> # yes, I am a Japanese :-)
>
> I understand it will be too heavy to support various of encodings.
> so, as alternative:
>
>  class XmlOutputter {
>    ...
>    std::string m_encoding;
>  public:
>    XmlOutputter( TestResult *result, std::ostream &stream, const char*
encoding="ISO-8859-1" )
[...]

[Cppunit-devel] Directory based testsuites

[Tredinnick, J. <jac...@me...>]

Hi,

Apologies for repeating a question I posted on the open forum a while ago -
I'm assuming this is a better place to get an answer?

I'm looking into using cppunit on a large application, for which the
requirement is to specify tests at run-time.
E.g to invoke all the tests under the directory $SRC/a/b:
<app> -test a.b

I couldn't quite manage to do this with the 1.6.2 release
(TestFactoryRegistry looked the best place to start), but eventually got it
working with a few changes in cppunit/extensions.

Surely I can't be the only one doing this?
Has anyone managed it with 1.6.2?  Is there any chance my changes could make
it into the next release?  (1.7.0 is it?)

Any advice would be appreciated.

Regards
--
Jacob Tredinnick

RE: [Cppunit-devel] complie error

[Sean Cook<se...@no...>]

I have determined that the compiler Workshop 4.2 does not support namespace
and since cppunit is written with support for namespace, I can not use it.
 
Cheers,
Sean 

-----Original Message-----
From: Baptiste Lepilleur [mailto:gai...@fr...]
Sent: Thursday, February 28, 2002 4:25 AM
To: Cook, Sean [GNVL:6520:EXCH]
Subject: Re: [Cppunit-devel] complie error


From:
"../../include/cppunit/Exception.h", line 4: Error: Could not open include
file <exception>. 
"../../include/cppunit/Exception.h", line 5: Error: Could not open include
file <string>. 

I would say that you have no STL library installed. Beyond that, I can't
help (don't know much about that platform).
 
Baptiste.

----- Original Message ----- 
From: Sean Cook <mailto:se...@no...>  
To: Cppunit (E-mail) <mailto:cpp...@li...>  
Sent: Wednesday, February 13, 2002 3:01 AM
Subject: [Cppunit-devel] complie error



Hello: When I compile cppunit I get an error. 
MY SYSTEM INFORMATION: 

hostname = santana 
uname -m = sun4u 
uname -r = 5.6 
uname -s = SunOS 
uname -v = Generic_105181-26 

/bin/arch              = sun4 
/usr/bin/arch -k       = sun4u 
/usr/convex/getsysinfo = unknown 
hostinfo               = unknown 
/bin/machine           = unknown 
/usr/bin/oslevel       = unknown 
/bin/universe          = unknown 

PATH =
/home/scook/bin:/usr/local/bin:/usr/ccs/bin:/opt/SUNWspro/bin:/usr/bin:/usr/
ucb:/etc:/usr/atria/bin:/usr/atria/etc.

(santana)[scook]> CC -V 
CC: WorkShop Compilers 4.2 16 Jun 1998 C++ 4.2 patch 104631-07 

THE PROBLEM: 

(santana)[scook]> make 
Making all in src 
make[1]: Entering directory `/home/scook/cppunit-1.6.2/src' 
Making all in cppunit 
make[2]: Entering directory `/home/scook/cppunit-1.6.2/src/cppunit' 
source='NotEqualException.cpp' object='NotEqualException.lo' libtool=yes \ 
depfile='.deps/NotEqualException.Plo'
tmpdepfile='.deps/NotEqualException.TPlo' \ 
depmode=none /bin/sh ../../config/depcomp \ 
/bin/sh ../../libtool --mode=compile CC -DHAVE_CONFIG_H -I. -I.
-I../../config -I../../include -I../../include    -g -c -o
NotEqualException.lo `test -f NotEqualException.cpp || echo
'./'`NotEqualException.cpp

CC -DHAVE_CONFIG_H -I. -I. -I../../config -I../../include -I../../include -g
-c NotEqualException.cpp  -KPIC -DPIC 
-o .libs/NotEqualException.o 
"../../include/cppunit/Exception.h", line 4: Error: Could not open include
file <exception>. 
"../../include/cppunit/Exception.h", line 5: Error: Could not open include
file <string>. 
"../../include/cppunit/Exception.h", line 7: Error: Type name expected
instead of "namespace". 
"../../include/cppunit/Exception.h", line 28: Error: std is not defined. 
"../../include/cppunit/Exception.h", line 28: Error: string must be
initialized. 
"../../include/cppunit/Exception.h", line 28: Error: "," expected instead of
"m_type". 
"../../include/cppunit/Exception.h", line 29: Error: Unexpected "}". 
"../../include/cppunit/Exception.h", line 32: Error: Type name expected
instead of "Exception". 
"../../include/cppunit/Exception.h", line 33: Error: UNKNOWNLINENUMBER is
not defined. 
"../../include/cppunit/Exception.h", line 34: Error: std is not defined. 
"../../include/cppunit/Exception.h", line 34: Error: Multiple declaration
for string. 
"../../include/cppunit/Exception.h", line 34: Error: "," expected instead of
"fileName". 
"../../include/cppunit/Exception.h", line 35: Error: ")" expected instead of
"&". 
"../../include/cppunit/Exception.h", line 37: Error: "virtual" is not
allowed here. 
"../../include/cppunit/Exception.h", line 37: Error: Type name expected
instead of "Exception". 
"../../include/cppunit/Exception.h", line 37: Error: Illegal number of
arguments for <destructor>(). 
"../../include/cppunit/Exception.h", line 39: Error: Type name expected
instead of "Exception". 
"../../include/cppunit/Exception.h", line 41: Error: The function "what()
const" cannot be declared const. 
"../../include/cppunit/Exception.h", line 43: Error: Multiple declaration
for lineNumber. 
"../../include/cppunit/Exception.h", line 44: Error: std is not defined. 
"../../include/cppunit/Exception.h", line 46: Error: std is not defined. 
"../../include/cppunit/Exception.h", line 46: Error: UNKNOWNFILENAME must be
initialized. 
"../../include/cppunit/Exception.h", line 47: Error: UNKNOWNLINENUMBER must
be initialized. 
"../../include/cppunit/Exception.h", line 49: Error: "virtual" is not
allowed here. 
"../../include/cppunit/Exception.h", line 49: Error: Type name expected
instead of "Exception". 
Compilation aborted, too many messages. 
make[2]: *** [NotEqualException.lo] Error 1 
make[2]: Leaving directory `/home/scook/cppunit-1.6.2/src/cppunit' 
make[1]: *** [all-recursive] Error 1 
make[1]: Leaving directory `/home/scook/cppunit-1.6.2/src' 
make: *** [all-recursive] Error 1 

Any suggestions? 

Cheers, 
Sean 

[Cppunit-devel] TestLogger

[Hauber, R. Dr., V. <rud...@lf...>]

Hi folks,
first of all thank you very much for your effort.
We have developed a simple logging facility for logging test results.
The class TestLogger is attached. It is very simple to use - see the example
below.
The background:
We use CppUnit for automated class and comonent testing generated from
Rational Rose
models in now 4 greater projects. It works very very good!
A script uses a class test template (based on the CppUnit classes) and
generates
the specialized class test code for selected classes in the model.
Corrsponding MS VC++ projects are generated too.
The class tests are added to Rational TestManager. In this way we can start
regression
test very simple: A batch file starts the make file and then the executible.
The logs are stored by TestLogger. 

----------------------------------------------------------------------------
----------
  TestLogger logger("<test_name>");

  TextTestResult *result = new TextTestResult;
  TestSuite *suite = MyClassTest::suite ();

  logger.logTestCases(suite);

  suite->run(result);

  if (result->wasSuccessful()) {
    std::cout << "test successfully passed" << std::endl;
    success = 0;
  }
  else {
    std::cout << "test not successful, see log file " <<
logger.getLogFileName() << std::endl;
    success = - ( result->testErrors()  + result->testFailures() );
  }

  // write the dump to the dump file
  logger.logTestResult(result);
----------------------------------------------------------------------------
----------
 <<TestUtil.h>>  <<TestUtil.cpp>> 
Regards
Rudi

________________________________________________________________
Dr. Rudolf Hauber			mailto:RH...@ka...
Koelsch & Altmann GmbH		fax:      +49-89-651071-91
Perlacher Str. 21			voice:   +49-89-651071-25
D-81539 Muenchen			mobile: +49-172-8945-297
Germany				http://www.ka-muc.de

[Cppunit-devel] CPPUNIT_ASSERT

[david m. <Dav...@Su...>]

Hi,

First I like your library!

I was woundering if you have seen CPPUNIT_ASSERT only works with simple
data types like:
      int rval = ioctl->issue_cmd (srb->get_uscsi_cmd ());
      CPPUNIT_ASSERT (rval == 0);

However when I do the following CPPUNIT_ASSERT fails because the srb
data is zeroed out by the macro:
    CPPUNIT_ASSERT (ioctl->issue_cmd (srb->get_uscsi_cmd ()) == 0);

I have also seen CPPUNIT_ASSERT fail where struct uscsi_cmd *srb is set
to null by the macro:
    CPPUNIT_ASSERT (srb != NULL);

I compiled the CPPUNIT library with Forte 6.2 by setting
CC=/opt/SUNWspro/bin/cc and CXX=/opt/SUNWspro/bin/CC before runing
./configure

Thanks,
David