cppunit-devel

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

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

>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=5Fiterator on a=
 vector<Test *>, and setting up the project. =

  There is also the need to change the =23include =22TestCase=22 to someth=
ing like =23include <TestCase> or =23include <cppunit/TestCase.h> (which i=
s better? I prefer the second because its avoid conflict but...).
  And that's true, the use of doxygen makes a very nice and useful documen=
tation (though the doc is not up to date (think TestCase autoregistration.=
..))

>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 window=
s
>system. =

  Yes, I found a few thing. I'll try it this evening. It's not your simple=
 point and click... And the docs 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 prod=
uce patch file.

>That one will definitely go in. Note that for your and mine (in)convenien=
ce,
>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 ?

>
>        - AutoRegisterSuite, a set of macros to make your life easier. Ye=
t,
>
>Arrggh, did you say 'macro'? Sorry, I'm very allergic to macros=21 :-) =

  Yes, my usual feeling. I'll write about that in the dev mailing list. Bu=
t as usual, it's an optionnal features. You don't like it, you don't use i=
t...

>        - 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 d=
o
>KDE and GNOME ports too. =

   Humm... I actualy enhanced it to make it more usuable (I believe so, at=
 least).

>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 t=
his
>has another benefit: by keeping the code needed to build unit test minima=
l,
>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 pr=
o/cons and how. I'd like to see what you aim exactly. I have further idea =
about integrating Unit testing with the IDE (having a Add-Ins that collect=
 failed test location and allows you to go just there would be nice).

>> For technical discussions about CppUnit development, please join the
>> devel mailinglist.
  Well, I sent the first mail: Test Registry... ;-)

  Baptiste.

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

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

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