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