cppunit-devel — CppUnit Developer Mailing List

Re: [Cppunit-devel] TestCaller interface change

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

As far as I know, all real initialization is done in setUp() and tearOf()
because you need that to be able to rerun the test.

Looking at the unit test I'm writing for Ttr, that's hold true. The
constructor and destructor of the testcase are usually left empty.

Though instead of removing the exisiting constructor, add a new one, so
people relying on that one won't have any problem.

It would also probably allow some nifty thing (having the same test run with
different setting or something like that).

I would also add a "void setFixture( Fixture *fixture)" method. So you could
write a decorator that iterates among a list of fixture and repeat the test
for each one.

----- Original Message -----
From: "Bastiaan Bakker" <bas...@li...>
To: <cpp...@li...>
Sent: Sunday, May 06, 2001 3:32 PM
Subject: [Cppunit-devel] TestCaller interface change


> Hi all,
>
> Baptiste's BoardGameTest problem, got me to look into TestCaller
> mechanism. As far as I can see, the main cause of the trouble is that
> every TestCaller constructs its own Fixture instance.
> I don't see any reason for that, so I'd like to change TestCaller to
> accept a reference to an existing TestCase.
> Please let me know if I'm wrong :-)
>
> Bastiaan
>
>
>
>
>
> _______________________________________________
> Cppunit-devel mailing list
> Cpp...@li...
> http://lists.sourceforge.net/lists/listinfo/cppunit-devel
>

Re: [Cppunit-devel] hierarchy sample bug...

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

> Baptiste Lepilleur wrote:
>
> >     Well, another stuff to clean up would be that one. There is a well
> > hidden bug in this sample dealing with hiearchy:
> >
> > In the template BoardGameTest:
> >
> >     virtual void registerTests(CppUnit::TestSuite *suite)
> >     {
> >       suite->addTest (new CppUnit::TestCaller<BoardGameTest>
("testReset",
> >          &BoardGameTest<GAMECLASS>::testReset));
> >       suite->addTest (new CppUnit::TestCaller<BoardGameTest>
("testReset",
> >          &BoardGameTest<GAMECLASS>::testResetShouldFail));
> >     }
> > => BoardGameTest class will be instantiated by each test caller.
> >
> > and:
> > class ChessTest : public BoardGameTest<GAMECLASS> {
> > ...
> >     void registerTests(CppUnit::TestSuite *suite)
> >     {
> >       BoardGameTest<GAMECLASS>::registerTests(suite);
> >       suite->addTest (
> >         new CppUnit::TestCaller<ChessTest> ("testNumberOfPieces",
> >           &ChessTest<GAMECLASS>::testNumberOfPieces));
> >     }
> > => for ChessTest we have the parent class test caller instantiating
> > BoardGameTest instead of ChessTest !!!!
> >
>
> That is correct behaviour. The BoardGameTest checks invariants that should
hold
> for all BoardGameTest instances, including Chess objects. The testReset()
> method in BoardGameTest should equally apply to Chess objects. Overriding
> testReset() in ChessTest is a serious indication that the design of
application
> is flawed.
    I agree with that. Though in some case you might have some "template
method" (the pattern) in your test case. I can see that applying when you
have some specific behavior and want to factor some testing part. An example
that pop up into my mind would be testing visitor/strategy/builder. The
setup of each test may be identical and you would want to factor out those
part in a base class. Then, you would use the self-shunt pattern (having the
test case implementing the visitor interface...), and delegate part of the
actual test to the derived test case.

> However, there is one problem, which may be what you hint at: the current
> BoardGameTest implementation implies that all BoardGame classes have a
default
> constructor and need no further setup.
    This is indeed the main problem I see. You want the setUp() and
tearOff() method of your derived class to be called: initialization of the
"game" class, initialization of the default database connection for the
current thread...

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] TestCaller interface change

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

Hi all,

Baptiste's BoardGameTest problem, got me to look into TestCaller
mechanism. As far as I can see, the main cause of the trouble is that
every TestCaller constructs its own Fixture instance.
I don't see any reason for that, so I'd like to change TestCaller to
accept a reference to an existing TestCase.
Please let me know if I'm wrong :-)

Bastiaan

Re: [Cppunit-devel] CppUnitW 1.2 merge

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

Baptiste Lepilleur wrote:

> > Merged like a charm. The dist tarball seems OK. I've put it in
> > http://www.cryptoforge.net/cppunit/cppunit-1.5.5.tar.gz for testing.
>
> "Seems" is the word. Everything is there but VC++ refuses to  open any of
> the workspaces or project file. I finally found out the problem: they are in
> the Unix format...
>

Hehe, I should have known that this was going to happen: only two days ago
somebody mailed me about the same problem with log4cpp.

>
> How can this be solved ?
> - A unix & a windows dist ?
> - I think I remember a flag for tar that allows conversion of text file to
> the local OS format, but I wasn't able to find that one (perhaps it's not on
> windows version of tar?).
>
> Any ideas ?
>

Yup, the solution is rather simple: I added " perl -pi -e 's/\n/\r\n/g' `find
$(distdir) -name '*.ds?'` " to the dist-hook target, so all *.ds? files are
converted to CRLF endings before the tar ball is made.
I've uploaded the new tar to cryptoforge. Please try it.

>
> The good news is that once this is fixed it can be released (I converted the
> file by hand and it worked just fine).
> Baptiste.
>

So the merge completed succesfully, that's good news indeed.
However I do want to clean up two things before a release:
* RTTI stuff
* TestCaller (BoardGameTest problem)

Bastiaan


>
> ---
> Baptiste Lepilleur <gai...@fr...>   http://gaiacrtn.free.fr/index.html
> Author of The Text Reformatter, a tool for fanfiction readers and writers.
> Language: English, French (Well, I'm French).
>
> _______________________________________________
> Cppunit-devel mailing list
> Cpp...@li...
> http://lists.sourceforge.net/lists/listinfo/cppunit-devel

Re: [Cppunit-devel] CppUnitW 1.2 merge

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

> Merged like a charm. The dist tarball seems OK. I've put it in
> http://www.cryptoforge.net/cppunit/cppunit-1.5.5.tar.gz for testing.

"Seems" is the word. Everything is there but VC++ refuses to  open any of
the workspaces or project file. I finally found out the problem: they are in
the Unix format...

How can this be solved ?
- A unix & a windows dist ?
- I think I remember a flag for tar that allows conversion of text file to
the local OS format, but I wasn't able to find that one (perhaps it's not on
windows version of tar?).

Any ideas ?

The good news is that once this is fixed it can be released (I converted the
file by hand and it worked just fine).
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] hierarchy sample bug...

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

Baptiste Lepilleur wrote:

>     Well, another stuff to clean up would be that one. There is a well
> hidden bug in this sample dealing with hiearchy:
>
> In the template BoardGameTest:
>
>     virtual void registerTests(CppUnit::TestSuite *suite)
>     {
>       suite->addTest (new CppUnit::TestCaller<BoardGameTest> ("testReset",
>          &BoardGameTest<GAMECLASS>::testReset));
>       suite->addTest (new CppUnit::TestCaller<BoardGameTest> ("testReset",
>          &BoardGameTest<GAMECLASS>::testResetShouldFail));
>     }
> => BoardGameTest class will be instantiated by each test caller.
>
> and:
> class ChessTest : public BoardGameTest<GAMECLASS> {
> ...
>     void registerTests(CppUnit::TestSuite *suite)
>     {
>       BoardGameTest<GAMECLASS>::registerTests(suite);
>       suite->addTest (
>         new CppUnit::TestCaller<ChessTest> ("testNumberOfPieces",
>           &ChessTest<GAMECLASS>::testNumberOfPieces));
>     }
> => for ChessTest we have the parent class test caller instantiating
> BoardGameTest instead of ChessTest !!!!
>

That is correct behaviour. The BoardGameTest checks invariants that should hold
for all BoardGameTest instances, including Chess objects. The testReset()
method in BoardGameTest should equally apply to Chess objects. Overriding
testReset() in ChessTest is a serious indication that the design of application
is flawed.
However, there is one problem, which may be what you hint at: the current
BoardGameTest implementation implies that all BoardGame classes have a default
constructor and need no further setup.
Lemme think this over.

Bye,

Bastiaan




>
> The way I found to correct this is to make registerTests() a template member
> :-(. This is done in the HelperMacros as follow:
>
>     static CppUnit::Test *suite()
>
>       __ThisTestCaseType *test =NULL;
>       CppUnit::TestSuiteBuilder<__ThisTestCaseType> suite;
>       __ThisTestCaseType::registerTests( suite, test );
>       return suite.takeSuite();
>     }
>
>     template<class TestCaseType>
>     static void
>     registerTests( CppUnit::TestSuiteBuilder<TestCaseType> &suite,
>                    TestCaseType *test )
>     {
>       __ThisSuperClassType::registerTests( suite, test )
>     ...
>     }
>
> At the current time, I haven't found any easier way to to this :-(. Any
> ideas ?
>
> 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 mailing list
> Cpp...@li...
> http://lists.sourceforge.net/lists/listinfo/cppunit-devel

Re: [Cppunit-devel] CppUnitW 1.2 merge

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

Baptiste Lepilleur wrote:

> Well, I finally made the patch. It includes:
>
> - compilation fix (include path, USE_TYPEINFO, TestFactoryRegistry.cpp move,
> ...).
> - CU_TEST_SUITE_REGISTRATION macro can be use on any class which have a
> static suite() method
> - partial memory leaks fix for TestFactoryRegistry: getRegistry() will not
> leak, but getRegistry( name) will.
>
> When this is integrated, we could probably try for a tarball to check if all
> files are correctly included.
>

Merged like a charm. The dist tarball seems OK. I've put it in
http://www.cryptoforge.net/cppunit/cppunit-1.5.5.tar.gz for testing.

A+,

Bastiaan


>
> See ya,
> 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).
>
>   ------------------------------------------------------------------------
>                                     Name: cppunitw1_2-mergefix.patch.gz
>    cppunitw1_2-mergefix.patch.gz    Type: application/x-compressed
>                                 Encoding: base64

[Cppunit-devel] hierarchy sample bug...

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

    Well, another stuff to clean up would be that one. There is a well
hidden bug in this sample dealing with hiearchy:

In the template BoardGameTest:

    virtual void registerTests(CppUnit::TestSuite *suite)
    {
      suite->addTest (new CppUnit::TestCaller<BoardGameTest> ("testReset",
         &BoardGameTest<GAMECLASS>::testReset));
      suite->addTest (new CppUnit::TestCaller<BoardGameTest> ("testReset",
         &BoardGameTest<GAMECLASS>::testResetShouldFail));
    }
=> BoardGameTest class will be instantiated by each test caller.

and:
class ChessTest : public BoardGameTest<GAMECLASS> {
...
    void registerTests(CppUnit::TestSuite *suite)
    {
      BoardGameTest<GAMECLASS>::registerTests(suite);
      suite->addTest (
        new CppUnit::TestCaller<ChessTest> ("testNumberOfPieces",
          &ChessTest<GAMECLASS>::testNumberOfPieces));
    }
=> for ChessTest we have the parent class test caller instantiating
BoardGameTest instead of ChessTest !!!!

The way I found to correct this is to make registerTests() a template member
:-(. This is done in the HelperMacros as follow:

    static CppUnit::Test *suite()


      __ThisTestCaseType *test =NULL;
      CppUnit::TestSuiteBuilder<__ThisTestCaseType> suite;
      __ThisTestCaseType::registerTests( suite, test );
      return suite.takeSuite();
    }

    template<class TestCaseType>
    static void
    registerTests( CppUnit::TestSuiteBuilder<TestCaseType> &suite,
                   TestCaseType *test )
    {
      __ThisSuperClassType::registerTests( suite, test )
    ...
    }

At the current time, I haven't found any easier way to to this :-(. Any
ideas ?

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] CppUnitW 1.2 merge

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

Well, I finally made the patch. It includes:

- compilation fix (include path, USE_TYPEINFO, TestFactoryRegistry.cpp move,
...).
- CU_TEST_SUITE_REGISTRATION macro can be use on any class which have a
static suite() method
- partial memory leaks fix for TestFactoryRegistry: getRegistry() will not
leak, but getRegistry( name) will.

When this is integrated, we could probably try for a tarball to check if all
files are correctly included.

See ya,
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] CppUnitW 1.2 merge

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

> I've merged most of CppUnitW 1.2, with some exceptions:
    Thanks, this is excellent !!!

>
> * TestFactoryRegistry used auto_ptr. I had to change that to ordinary
> pointers: auto_ptr's cannot be used inside STL containers (see for
> example:  http://gcc.gnu.org/onlinedocs/libstdc++/20_util/howto.html ).
> With MSVC++ it may work (by accident), but with g++ is doesn't even
> compile. For now, I've only changed pointer types and not done anything
> about the memory management: very likely it will leak now. Please have a
> look at it.
    Thanks for pointing that out. I aware of this limitation (and even with
VC++ your going into trouble if you're using sort(). It's also one of the
reason auto_ptr had such an hard time getting into stl). I did this as a
quick hack to test the thing and completly forgot to clean it up.
    I'll send a patch tomorrow I hope to fix the leaks. Though there is
still some problem when doing:

TestFactoryRegistry::getRegistry().registerFactory( "Functionnal tests",
TestFactoryRegistry::getRegistry( "Functionnal" ) );

Since the registry owns the factories, it will be destroyed twice (owned by
getRegistry( aName ) and registerFactory() ). I'm still turning this around
to see how I can fix that.

>
> * I've put the typeinfo stuff in TestSuite and TestFactoryRegistry
> inside "#ifdef USE_TYPEINFO ".  RTTI is still rather new and may not be
    I would rather use CU_USE_TYPEINFO or something like that
(CU_NO_TYPEINFO would be easier for us since we wouldn't need to declare it
in each project). Prefixes are a great help when you have tens of
precompiler define and you need to figure out which library they are related
to (and with VC++ you a 40 chars edit field to see them all :-( ).

> supported properly on all platforms. Since it's only used to create
> TestSuites with names direved from a class name, I did not not feel
> dependence of the core library on RTTI was justified. Also deriving the
    I agree with that. since it has been available with VC++ for years (it
was there in VC++ 5.0), I though it was a rather comon feature by now. Well
I guessed wrong... ;-(

> class name through type_info is an unreliable method. Once again the C++
> comittee managed to kill a useful feature: not only may the string
> returned by type_info.name() differ from compiler to compiler (e.g. g++
> returns some really ugly mangled name), but differ with different runs
> of the program as well. Of course this renders the whole method useful.
    Yukk! Do raw_name() and name() return the same thing (raw_name is not
supposed to be human readable, but name() is supposed to be....) ?

> If someone can explain why the comittee has done this, please do!
    Damn. I though this one bit was at least well specified. I guess the use
will mainly be for VC++ user. I'll add another constructor to
TestSuiteBuilder so the suite name can be specified by hand.

>
> * Changed TestSuite.getTests() to return a const ref.
    Well, I find the original one easier to use, but I won't arg about that.

>
> * Moved TestFactoryRegistry.cpp from src/cppunit/extensions to
> src/cppunit. It is part of the main library anyway and is much easier to
> configure automake for it.
    I'll need to fix the VC++ project. Will be in the patch to.
>
> Please give it a try and let me know where I messed up.
    So did I...
    TestAssert.cpp is missing.

    There is also a few minor things (include path in TestRegistry.cpp, typo
in TestRunnerModel.cpp). I'll put those in the patch.

    Other than that it works just fine. Hopefully, I make the patch tomorrow
and we'll soon have a working version !

    Thanks a lot Baastian.

    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] CppUnitW 1.2 merge

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

Hi Baptiste (and everyone else),

I've merged most of CppUnitW 1.2, with some exceptions:

* TestFactoryRegistry used auto_ptr. I had to change that to ordinary
pointers: auto_ptr's cannot be used inside STL containers (see for
example:  http://gcc.gnu.org/onlinedocs/libstdc++/20_util/howto.html ).
With MSVC++ it may work (by accident), but with g++ is doesn't even
compile. For now, I've only changed pointer types and not done anything
about the memory management: very likely it will leak now. Please have a
look at it.

* I've put the typeinfo stuff in TestSuite and TestFactoryRegistry
inside "#ifdef USE_TYPEINFO ".  RTTI is still rather new and may not be
supported properly on all platforms. Since it's only used to create
TestSuites with names direved from a class name, I did not not feel
dependence of the core library on RTTI was justified. Also deriving the
class name through type_info is an unreliable method. Once again the C++
comittee managed to kill a useful feature: not only may the string
returned by type_info.name() differ from compiler to compiler (e.g. g++
returns some really ugly mangled name), but differ with different runs
of the program as well. Of course this renders the whole method useful.
If someone can explain why the comittee has done this, please do!

* Changed TestSuite.getTests() to return a const ref.

* Moved TestFactoryRegistry.cpp from src/cppunit/extensions to
src/cppunit. It is part of the main library anyway and is much easier to
configure automake for it.

Please give it a try and let me know where I messed up.

Thanks,

Bastiaan

Re: [Cppunit-devel] Patch for VC++ testrunner...

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

> Sometimes you may  have files in the CVS repository you do not want in a
> release: e.g. new, immature classes that are not ready for release yet.
    Yes, that make sens.

> But more importantly, make creates the dist tarball from a local checkout,
> after ./configure has run. At this time the dirtree contains localized
> generates files, like Makefiles, config.h and maybe other stuff as well.
> Furthermore all kind of other stuff generated during development, like
core
> dumps, editor backups, patch rejects, etc., etc. occuppy the dir tree as
well.
> So one would have to be selective about what to copy and what not, anyway.
> In general I think it's better if one consciously choose what goes in the
dist
> and what not.
    That match the way I'm doing my "dist" on windows: copy the directory
tree, then run a "clean-up" batch file (It's easier to say what to clean up
that to say what to keep).

    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] Patch for VC++ testrunner...

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

Baptiste Lepilleur wrote:

> > The borland port seems not to use MFC, indeed. But it looks like the
> msvc++ and
> > borland versions share large parts of the code.  Better to have that part
> in
> > the tree only once, and abstract the GUI interface.
> > So I still prefer a win32 subdir over an msvc one: when someone wants to
> > support borland, s/he can start from there and split out the concrete GUI
> > calls.
>     I gave it a quick look, and the closest common stuff I could find was
> the GUITestResult class, yet even the synchronization mecanism was removed
> (it look like the Borland version does not run the test in a separate
> thread). Not worth factoring out, since it would make it hard to change a
> project without impacting the other, therefore reducing the velocity of
> change.
>     The test runner itself is pretty simple : 1 class for the dialog, 1
> class that prograte result to the dialog, 1 class for the ActiveTest
> (threaded test), and a few other support class that don't to much. Each of
> this is compiler specific....
>

OK, I just briefly glanced over it and saw that both had a lot of filenames in
common, which hinted at a similar structure  at least. Apparently it's not that
simple :-(
I'll let the portability issue rest until someone actually wants to spend
effort into supporting borland or other compilers.


>
> > OK, it does not work. But I've found another way, which is more
> convenient:
> > With the 'dist-hook' target one can specify commands to run after the dist
> dir
> > has been created, but before it has been tarred. Here we can simply copy
> the
> > msvc directories. No need for a separate Makefile.am in alls directories.
>     Hmm, couldn't this be applied to everything, I mean I can't see a file
> in the CVS repository that should not be in the "release" tarball.
>

Sometimes you may  have files in the CVS repository you do not want in a
release: e.g. new, immature classes that are not ready for release yet.
But more importantly, make creates the dist tarball from a local checkout,
after ./configure has run. At this time the dirtree contains localized
generates files, like Makefiles, config.h and maybe other stuff as well.
Furthermore all kind of other stuff generated during development, like core
dumps, editor backups, patch rejects, etc., etc. occuppy the dir tree as well.
So one would have to be selective about what to copy and what not, anyway.
In general I think it's better if one consciously choose what goes in the dist
and what not.

Bastiaan

>
>     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 mailing list
> Cpp...@li...
> http://lists.sourceforge.net/lists/listinfo/cppunit-devel

Re: [Cppunit-devel] Patch for VC++ testrunner...

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

> The borland port seems not to use MFC, indeed. But it looks like the
msvc++ and
> borland versions share large parts of the code.  Better to have that part
in
> the tree only once, and abstract the GUI interface.
> So I still prefer a win32 subdir over an msvc one: when someone wants to
> support borland, s/he can start from there and split out the concrete GUI
> calls.
    I gave it a quick look, and the closest common stuff I could find was
the GUITestResult class, yet even the synchronization mecanism was removed
(it look like the Borland version does not run the test in a separate
thread). Not worth factoring out, since it would make it hard to change a
project without impacting the other, therefore reducing the velocity of
change.
    The test runner itself is pretty simple : 1 class for the dialog, 1
class that prograte result to the dialog, 1 class for the ActiveTest
(threaded test), and a few other support class that don't to much. Each of
this is compiler specific....

> OK, it does not work. But I've found another way, which is more
convenient:
> With the 'dist-hook' target one can specify commands to run after the dist
dir
> has been created, but before it has been tarred. Here we can simply copy
the
> msvc directories. No need for a separate Makefile.am in alls directories.
    Hmm, couldn't this be applied to everything, I mean I can't see a file
in the CVS repository that should not be in the "release" tarball.

    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] Patch for VC++ testrunner...

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

Baptiste Lepilleur wrote:

> >
> > I see.
> > One question: is the test runner MSVC++ specific per definition? If not,
> I'd prefer to put the
> > files in a win32 sub directory, rather than 'msvc6'. People may want to
> compile under a different
> > compiler than MSVC++.
>     It use MFC. I think it is possible to use MFC with other compiler but
> I'm not sure (the sure of the MFC use lot of compiler specific stuff).
> Borland comes with its one set of "gui" class, if I remember well. I'll try
> to check the borland version on xprogramming to see if anything was kept
> from the original GUI. Plus there is the fact that C++ dll produced by VC++
> can only be linked with C++: Borland and VC++ do not decorate the name the
> same way  :-(.
>

The different name mangling is intentional: with the same mangling scheme the
apps would link, but crash due to incompatible implementions of exceptions,
RTTI, etc.
The borland port seems not to use MFC, indeed. But it looks like the msvc++ and
borland versions share large parts of the code.  Better to have that part in
the tree only once, and abstract the GUI interface.
So I still prefer a win32 subdir over an msvc one: when someone wants to
support borland, s/he can start from there and split out the concrete GUI
calls.


>
> > >     I also added the makefile.am in each new directory (hope I did not
> > > forget one), and added them to the SUBDIR variable. The dsp and dsw have
> > > been added to the EXTRA_DIST. Should the .cpp and .h be added to ? If
> so,
> > > could this be done using shell command (something akin to EXTRA_DIST =
> `ls
> > > *.h *.cpp *.ico *.rc *.bmp`) ?
> > >
> >
> > I'm not sure if a shell command would work. I'll try to find out.
>
>     Thanks.
>

OK, it does not work. But I've found another way, which is more convenient:
With the 'dist-hook' target one can specify commands to run after the dist dir
has been created, but before it has been tarred. Here we can simply copy the
msvc directories. No need for a separate Makefile.am in alls directories.

Bastiaan


>
>     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 mailing list
> Cpp...@li...
> http://lists.sourceforge.net/lists/listinfo/cppunit-devel

Re: [Cppunit-devel] Patch for VC++ testrunner...

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

>
> I see.
> One question: is the test runner MSVC++ specific per definition? If not,
I'd prefer to put the
> files in a win32 sub directory, rather than 'msvc6'. People may want to
compile under a different
> compiler than MSVC++.
    It use MFC. I think it is possible to use MFC with other compiler but
I'm not sure (the sure of the MFC use lot of compiler specific stuff).
Borland comes with its one set of "gui" class, if I remember well. I'll try
to check the borland version on xprogramming to see if anything was kept
from the original GUI. Plus there is the fact that C++ dll produced by VC++
can only be linked with C++: Borland and VC++ do not decorate the name the
same way  :-(.

> >     I also added the makefile.am in each new directory (hope I did not
> > forget one), and added them to the SUBDIR variable. The dsp and dsw have
> > been added to the EXTRA_DIST. Should the .cpp and .h be added to ? If
so,
> > could this be done using shell command (something akin to EXTRA_DIST =
`ls
> > *.h *.cpp *.ico *.rc *.bmp`) ?
> >
>
> I'm not sure if a shell command would work. I'll try to find out.

    Thanks.

    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] VC++ Add-Ins for IDE integration of Unit test result

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

> Great, integration with VC++ will make a lot of people happy I think.
> One note: under what license are the above pieces of code released? I ask,
because
> Win32 code seems to be released under a free license far less often than
*nix
> code.
    There isn't even a license provided with Open/VC. It is a "used at your
one risk". Open/VC is a code generator that build the squeleton of the
Add-Ins.
    Quoting the license for WWhizInterface:

"The license from the Workspace Whiz! source distribution (which includes
WWhizInterface) reads:

Workspace Whiz! - A Visual Studio Add-in Source Code
(http://workspacewhiz.com/) is Copyright 1999-2001 by Joshua C. Jensen
mailto:jj...@wo...).
  The code presented in this source distribution may be freely used and
  modified for all non-commercial and commercial purposes so long as due
credit
  is given and the source file header is left intact.

  If the source module is from another author, that module may be used
  subject to the restrictions of the author.

  Workspace Whiz! and its accompanying files are provided "as is."
  The author can not be held liable for any damages caused through the use
of
  this software, except for refund of the purchase price."

    If I read thing correctly, there should not be any problem. It as
already been used in others add-ins. (And Workspace Whiz is a shareware well
worth acquiring if your using VC++ on a ady to day basis).

> >      - The Add-ins detects the file update (how?), processes the result
> > (translate absolute path name to project relative file...).
> >
>
> If I remember correctly the Win32 API has a feature with which a process
can
> request a notification when a certain directory or file changes.
    Yes, I've been considering this, thought it is only supported on Windows
NT and 2000. There a nice wrapper class for this
(http://www.codeproject.com/useritems/directorychangewatcher.asp). But it
might do for a first version since most of the developper work on NT. For
the other, a simple "refresh" button would do the job.

> The emacs method is very simple: if you choose 'compile' under the tools
menu,
> emacs will run an external program (by default 'make -k').  It then puts
the
> output of this program in a separate buffer. This program (usually gcc or
g++)
> outputs it messages in the format '<filename>:<linenumber>: <message>'.
Emacs
> 'knows' this simple format, so if you display the output buffer and click
on one
> of these lines, emacs will display the corrresponding file at the correct
line.
> That's all.
>
> This would work with the Java test runner too.
    This can also work on VC++. If you print message to the debug output (a
specific WIN32 API), you can see them in the "debug" window of VC++. If the
line happen to look like:
h:\devstudio\include\xtree(120) : warning C4786: 'std::_Tree<std
    You can go in the source by double clicking it (and switch from one to
the other using CTRL+F4, CTRL+SHIFT+F4).
    So a basic text mode with IDE integration could be done. It would be
differ from the emacs one:
        - different format for reporting the location of the message
        - different API used to "print" the message.

    On the other hand, this debug output tends to be a real clutter, DLL
loading appears there, memory leaks too (when using VC++ the libc features),
and thread termination (a real bother in MT application), and the usual
TRACE developper put in the code when debugging.
    I'll try to add this in the VC++ TestRunner.

    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] Re: RE: Integrating CppUnit Windows edition...

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

> Hmm, I guess you need a macro for that. But it's only to save you from
typing
> 'testMethod' twice, not very exciting.
    Yes, but you're assured that the name is the correct one (I usally don't
look the location but the class/method which are in the test name.). I guess
I'll try it both way when I have time and decide if the macros are worth it.

> Well, I guess the 'industrial strength' way is to use a text based
testrunner
> on the nightly build and automatically mail the test failures to the
respective
> maintainers of the code.
    Hmm, from what I understand of XP, the code is never integrated unless
all tests pass and they should be quick to run (since you refactor &
integrate often).
Plus there should not be code ownership. Of course, this does not apply if
you use cppunit with other "method". The process you depict would work well
in the context of open source project, I think.

> But for manual runs, I'd put a breakpoint  in constructor of Exception()
and
> navigate up a few stack frames when it gets hit by a failed test. Doesn't
> really matter if you use a graphical test runner or not.
    Yes I thought of that too. I tried to do that using an C assert, and
have a setting to decide weither or not an exception is thrown, but since
the library is linked to each component (the exe, the testrunner dll, and
your other dll), the setting would apply only to the current component. In
the end, I'll try to see if the add-ins could add or remove the
break-point).

> The reasons why I let Java start the test program and not the other way
around
> is that C++ doesn't have a portable method of spawning new processes: *nix
has
> fork() but Win32 uses something else.
    Hmm that only make two differents way. Wouldn't be to hard to handle
both (strategy?). How do you get to use the break-point trick ? With VC++,
you need attach the debugger to the process first, then chase down the
Exception source and set the breakpoint. The bad part is attching the
debugger (you can't to a macro that do that).

---
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] Patch for VC++ testrunner...

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

Baptiste Lepilleur wrote:

>     I finally made the patch. It's in the attached file. The
> bin-examples.tar.gz contains the binary files and should be unpacked above
> examples/.
>

I see.
One question: is the test runner MSVC++ specific per definition? If not, I'd prefer to put the
files in a win32 sub directory, rather than 'msvc6'. People may want to compile under a different
compiler than MSVC++.

>
>     The patch includes Michael's Feather test runner (slightly modified to
> avoid conflict when compiling). I'll include my enhancement later, once I
> cleaned it a bit. It's also include the original sample application that
> show how to use the test runner. CppUnit extensions have also been added
> (include/cppunit/extensions).
>
>     I also added the makefile.am in each new directory (hope I did not
> forget one), and added them to the SUBDIR variable. The dsp and dsw have
> been added to the EXTRA_DIST. Should the .cpp and .h be added to ? If so,
> could this be done using shell command (something akin to EXTRA_DIST = `ls
> *.h *.cpp *.ico *.rc *.bmp`) ?
>

I'm not sure if a shell command would work. I'll try to find out.

>
>     I played around with cvs. How to you get it to make a patch containing
> the binary file ? This is the command line I'd used (I didn't used it
> because of the EOL problem with the dsp/dsw, but once it is fixed I plan to
> use that):
>
> cvs rdiff -R -u -r tg-cppunitsf-sf-1 -r tg-cppunitsf-trunc-patch-testrunner
> sf/cppunit > testrunner.patch
>
>     How do you get it to do: "for the binary file, I want you to include the
> version of the second revision if they are different." Same question using
> diff.
>

According to the man/info pages, diff cannot output the contents of binary files.
But again, I'll see if some solution is available.

>
>     Once all this is merged, could a tarball be generated so I can check if
> no file is missing ? Once this is validated, we could probably make a
> release. I think I'll write a small html page "build guide for win32".
>

Once your patches have been merged, I'll put a tar ball in the projects FTP section.
Could you send me the html page? Seems like a good addition in the doc dir.


Bastiaan


>
>     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).
>
>   ------------------------------------------------------------------------
>                                                     Name: cppunit-testrunner-bin-examples.tar.gz
>    cppunit-testrunner-bin-examples.tar.gz           Type: Unix Tape Archive (application/x-tar)
>                                                 Encoding: base64
>                                          Download Status: Not downloaded with message
>
>                                          Name: cppunit-testrunner.patch.gz
>    cppunit-testrunner.patch.gz           Type: application/x-compressed
>                                      Encoding: base64
>                               Download Status: Not downloaded with message

Re: [Cppunit-devel] Re: RE: Integrating CppUnit Windows edition...

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

Baptiste Lepilleur wrote:

-8<-

>     Well, actually the stuff is template based. The macro are just the final
> step needed so that you don't need to do builder.addTest( "tesMethod",
> testMethod ). Sadly, I don't know of any other way to achieve that :-(.
>

Hmm, I guess you need a macro for that. But it's only to save you from typing
'testMethod' twice, not very exciting.

>
> > I'll try to hack a crude version ASAP. Basically the idea is to have a
> command driven test runner which produces text results that Java easily can
> parse. So I start a graphical runner in Java and that runner starts the C++
> test program as a subprocess and communicates withit through standard
> > in- and output.
> > The test program only needs the CppUnit core classes and a highly portable
> text command and testresult implementation. So it's easy to write this cross
> platfrom. Also it eliminates the risk that the libs the GUI TestRunner uses
> conflict with those your app uses. For example the (Java) GUI
> > TestRunner may use (nonnative) green threads will the classes you want to
> test use LinuxThreads.
>
> I'm not sure the same level integration could be reached. As I work
> actually, I run my application from the IDE, the test runner automatically
> run the last select test (usually the "All test" suite). Second later, I see
> if there is a problem or no. If a test failed, I usually put a break in the
> debugger to see exactly where it failed (we lack the stack trace feature of
> java :_( ), then I rerun the test. On the other hand, I only work on my
> small project at home, and I don't have the experience of an industrial
> strength project, so may be you proceed in some other way.
>

Well, I guess the 'industrial strength' way is to use a text based testrunner
on the nightly build and automatically mail the test failures to the respective
maintainers of the code.
But for manual runs, I'd put a breakpoint  in constructor of Exception() and
navigate up a few stack frames when it gets hit by a failed test. Doesn't
really matter if you use a graphical test runner or not.

>
> Well, the point is how to you get java to open the debugger on the failed
> test ? If it was done the other way (eg you run the c++ program first), I
> could see the thing working.
>

I see from your later mail you already tackled this problem, by coupling to the
adding using an output file.
The reasons why I let Java start the test program and not the other way around
is that C++ doesn't have a portable method of spawning new processes: *nix has
fork() but Win32 uses something else.

Bastiaan


>
> >
> > > Add-Ins that collect failed test location and allows you to go just
> there would be nice).
> > >
> >
> > yakTest (also on SourceForge) generates test results in Emacs compatible
> format, we easily could do the same.
> Glad to see I'm not the only one to thing about that.
>
> 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] VC++ Add-Ins for IDE integration of Unit test result

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

Baptiste Lepilleur wrote:

>    Well, I started looking at how add-ins work for VC++. It seems to be a
> possible things to do (I don't know a thing about that, so I'll be discovering
> things there). I'll base the add-ins on
> http://www.codeproject.com/macro/openvc.asp, a code base to make VC++ add-ins,
> and http://www.codeproject.com/useritems/wwhizinterface.asp which is a nice
> helper to use VC++ automation.
>

Great, integration with VC++ will make a lot of people happy I think.
One note: under what license are the above pieces of code released? I ask, because
Win32 code seems to be released under a free license far less often than *nix
code.

>
>    Here is how I see things working:
>      - You launch the test runner as usual. You get your visual feedback
> (red/green). The result of the testing is also written into a file (I should be
> possible to use something like a composite TestResult do to that).
>      - The Add-ins detects the file update (how?), processes the result
> (translate absolute path name to project relative file...).
>

If I remember correctly the Win32 API has a feature with which a process can
request a notification when a certain directory or file changes.


>    Is the process similar with emacs. Can the composant that generates the file
> with the test result be comon ? Does it fit with the output of the java test
> runner you talked about (or at least part of it) ?
>

The emacs method is very simple: if you choose 'compile' under the tools menu,
emacs will run an external program (by default 'make -k').  It then puts the
output of this program in a separate buffer. This program (usually gcc or g++)
outputs it messages in the format '<filename>:<linenumber>: <message>'. Emacs
'knows' this simple format, so if you display the output buffer and click on one
of these lines, emacs will display the corrresponding file at the correct line.
That's all.

This would work with the Java test runner too.

Bastiaan


>
>    Baptiste.
>
> ---
> Baptiste Lepilleur <gai...@fr...>
> http://gaiacrtn.free.fr/index.html
>
> _______________________________________________
> Cppunit-devel mailing list
> Cpp...@li...
> http://lists.sourceforge.net/lists/listinfo/cppunit-devel

[Cppunit-devel] Patch for VC++ testrunner...

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

    I finally made the patch. It's in the attached file. The
bin-examples.tar.gz contains the binary files and should be unpacked above
examples/.

    The patch includes Michael's Feather test runner (slightly modified to
avoid conflict when compiling). I'll include my enhancement later, once I
cleaned it a bit. It's also include the original sample application that
show how to use the test runner. CppUnit extensions have also been added
(include/cppunit/extensions).

    I also added the makefile.am in each new directory (hope I did not
forget one), and added them to the SUBDIR variable. The dsp and dsw have
been added to the EXTRA_DIST. Should the .cpp and .h be added to ? If so,
could this be done using shell command (something akin to EXTRA_DIST = `ls
*.h *.cpp *.ico *.rc *.bmp`) ?

    I played around with cvs. How to you get it to make a patch containing
the binary file ? This is the command line I'd used (I didn't used it
because of the EOL problem with the dsp/dsw, but once it is fixed I plan to
use that):

cvs rdiff -R -u -r tg-cppunitsf-sf-1 -r tg-cppunitsf-trunc-patch-testrunner
sf/cppunit > testrunner.patch

    How do you get it to do: "for the binary file, I want you to include the
version of the second revision if they are different." Same question using
diff.

    Once all this is merged, could a tarball be generated so I can check if
no file is missing ? Once this is validated, we could probably make a
release. I think I'll write a small html page "build guide for win32".

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

Fw: [Cppunit-devel] Re: [CppUnit] New repository layout...

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

    This is the mail I sent yesterday evening that did not get through:

> OK, I've merged this patch, it's in CVS now.
> A note for if you add project files in the future:
> simply adding them to CVS will not ensure that they end up in the dist
tarball
> as well. To get them in, they need to be added to the EXTRA_DIST variable
in
> the Makefile.am file in the same directory. For example
cppunit/Makefile.am
> contains:
>
> EXTRA_DIST = cppunit.dsw cppunit.dsp
Well, I'll do that for the next patch.

> >   How do you apply a patch? understand: what are the magic options ;-) ?
> >
>
> That's easy:
>
> cd topdir
> patch -p1 < improvement.patch
>
> The '-pN' option will strip N slashes from the front of filenames. So
with -p1,
> cppunit/cppunit/cppunit.dsp becomes cppunit/cppunit.dsp.
        Thanks you very much !

> >   - adding Michael's Feather framework/extensions back into the project.
> > What should be the physical layout ? include/cppunit/extensions ?
>
> That makes sense. Same as X11/extensions
        I have it ready. I need to make the patch, but that'll be for
tomorow (I hope).
        I've put the thing as follow:
        examples/msvc6/HostApp        for Michael Feather's original sample
(with change for compilation, of course)
        include/msvc6/testrunner/TestRunnerDlg.h    for the test runner
include. I'm not sure its the right way. When using cppunit, you need to add
2 paths. Perhaps it would be better to use different name for each platform:
include/testrunner-vc ? We have to think about the future test runner,
what's the planned layout ?
        src/msvc6/testrunner        for the testrunner dynamic library. The
library is build to lib/testrunnerd.dll and lib/testrunnerd.lib.

> I didn't have a look at the registry patch yet, I'll let you know when I
have.
    Hummm, I've been thinking about the registry a lot lately... One of the
reason, I've used the original version of the testrunner is that when you
pass the test to the runner, you grant him the ownership of those tests. The
registry owns the tests. It's incompatible.
    So you might as well kill it (I'll still be using a registry, but not a
test registry. Probably something like a suite factory registry). Thought
you might want to apply the patch since it remove the registry usage for the
TestCase (and fixes the doc).
---
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] VC++ Add-Ins for IDE integration of Unit test result

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

   Well, I started looking at how add-ins work for VC++. It seems to be a 
possible things to do (I don't know a thing about that, so I'll be discovering 
things there). I'll base the add-ins on 
http://www.codeproject.com/macro/openvc.asp, a code base to make VC++ add-ins, 
and http://www.codeproject.com/useritems/wwhizinterface.asp which is a nice 
helper to use VC++ automation.

   Here is how I see things working:
     - You launch the test runner as usual. You get your visual feedback 
(red/green). The result of the testing is also written into a file (I should be 
possible to use something like a composite TestResult do to that). 
     - The Add-ins detects the file update (how?), processes the result 
(translate absolute path name to project relative file...).

   Is the process similar with emacs. Can the composant that generates the file 
with the test result be comon ? Does it fit with the output of the java test 
runner you talked about (or at least part of it) ?

   Baptiste.

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

RE: [Cppunit-devel] Re: [CppUnit] New repository layout...

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

-----Oorspronkelijk bericht-----
Van: Baptiste Lepilleur [mailto:bl...@cl...]
Verzonden: Friday, April 20, 2001 9:42 AM
Aan: cpp...@li...
Onderwerp: Re: [Cppunit-devel] Re: [CppUnit] New repository layout...


> OK, I've merged this patch, it's in CVS now.

    I checked it out. There has been a problem. Each line of the new file
(dsp,dsw) ends with "\r\r\n" instead of "\r\n". My guess is that the unix
version of patch did not recognize the diff file has being a windows format
file, and created the new text file in the windows format on the unix
machine. I'll submit the next patch in the unix format, and hopefully it
will correct that problem.

No, my guess is that it's my own fault :-).
The patch utility very conveniently recognizes CRLF line endings and
converts them to LF. To be helpful, I converted the dsw and dsp files back
to CRLF. 
Now, when you check out files on windows, CVS will already automatically
convert LF's to CRLF's. In our case that leaves you with CRCRLF :-(
I'll update the files to LF line endings.

    Also, the patch for cppunit/examples/hierarchy/main.cpp is missing.

Ah, yes, good of you to remind me: when applied your patch, the one on
main.cpp was rejected because of changes I'd already made to the file
myself. I'll try to merge it by hand.

Bastiaan

    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 mailing list
Cpp...@li...
http://lists.sourceforge.net/lists/listinfo/cppunit-devel