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

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

bl...@cl... wrote:

> >I must admit, autoconf doesn't help you a single bit, if you use MSVC++, but
> >I think .dsw and .dsp files can easily be added to the tree, if someone
> >supplies them.
>   Yes, having it compiling on VC++ was not difficult (some missing std::, and a iterator on a vector<Test *const> instead of a const_iterator on a vector<Test *>, and setting up the project.
>   There is also the need to change the #include "TestCase" to something like #include <TestCase> or #include <cppunit/TestCase.h> (which is better? I prefer the second because its avoid conflict but...).

It is and will be the second (#include <cppunit/TestCase.h>).

>
>   And that's true, the use of doxygen makes a very nice and useful documentation (though the doc is not up to date (think TestCase autoregistration...))

Yes, we need a volunteer to clean up the docs. I don't have time at the moment :-(

>
>
> >platform. But I think in one of the SourceForge forums there must be some
> >docs about it, you're not the only SourceForge member working on a windows
> >system.
>   Yes, I found a few thing. I'll try it this evening. It's not your simple point and click... And the docs

Actually I think command line CVS is simpler, but then again I'm not a windoze user :-)

>

> are not as clear as I whish they were.
>
> >diff utility. To make a diff between two directory trees (the original
> >untouched one, and one you modified) use:
> >
> >diff -Naur cppunit.orig cppunit > cppunit.patch
>   I'll do this. As far as I know, the diff function of WinCVS can not produce patch file.
>

OK, I didn't know that.

>
> >That one will definitely go in. Note that for your and mine (in)convenience,
> >I've started moving files around (only the header files I believe) after the
> >1.5.4 release. I expect to do some more shuffling, to keep the framework
> >sources from the extension sources.
>   Let me know when you have a relatively stable version. Are those change in CVS HEAD ?

All changes up until now are in CVS HEAD, didn't  create multiple branches yet. Maybe later if enough people are joining in, we may have a 'stable'  and a 'devel' branch.

>
> >
> >        - AutoRegisterSuite, a set of macros to make your life easier. Yet,
> >
> >Arrggh, did you say 'macro'? Sorry, I'm very allergic to macros! :-)
>   Yes, my usual feeling. I'll write about that in the dev mailing list. But as usual, it's an optionnal features. You don't like it, you don't use it...
>

And doesn't get committed to CVS... :-)
No, seriously, even though stuff may be optional, once it's in the main tree it still has to be maintained.
And I don't want to encourage other people to submit patches/fixes with macro's either.
Also, the things you want to do, you probably can do properly with templates too.

>
> >        - TestRunner GUI application for Windows.
> >
> >Yes, I'd like to see that back in the main tree too, even though I won't use
> >it. I think it's one of the reasons win32 people still stick to Michaels
> >version. Having it in the tree hopefully will encourage other people to do
> >KDE and GNOME ports too.
>    Humm... I actualy enhanced it to make it more usuable (I believe so, at least).
>

Maybe I'm redundant, but the reason I won't use the windows TestRunner has nothing to do with me liking it or not, but with the simple fact that I don't and won't use windows for development.

>
> >However, I do prefer a cross platform TestRunner. Therefore one of my
> >ambitions is to couple the JUnit runner to CppUnit tests through standard
> >in- and output and XML test reports. Besides the cross platform support this
> >has another benefit: by keeping the code needed to build unit test minimal,
> >one also minimizes the chance of conflicts, e.g. MFC vs other widget set or
> >Java green threads vs POSIX threads.
>   We'll have to discuss that point on the mailing list. There plenty of pro/cons and how. I'd like to

Uh, we're already on the mailing list :-)
I set the reply-to to cpp...@li..., remember?

> see what you aim exactly. I have further idea about integrating Unit testing with the IDE (having a

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.
Someone has written 'CppBridge' which also allows you to run CppUnit tests from the JUnit TestRunner, but couples through generated native JNI code. So in effect it links the C++ classes into the JavaVM, which introduces the problems mentioned above.

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

Bastiaan

P.S. The mailing list is currently set to 'reply to sender' and not 'reply to list' so you manually have to adapt the 'To' address to the list address when you reply.
Once I receive the mailman admin password from J.E. I'll correct it.

>
> >> For technical discussions about CppUnit development, please join the
> >> devel mailinglist.
>   Well, I sent the first mail: Test Registry... ;-)
>
>   Baptiste.
>
> ---
> Baptiste Lepilleur <gai...@fr...>
> http://gaiacrtn.free.fr/index.html
> Language: English, French
>
> _______________________________________________
> Cppunit-devel mailing list
> Cpp...@li...
> http://lists.sourceforge.net/lists/listinfo/cppunit-devel