cppunit-devel — CppUnit Developer Mailing List

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

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

> 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.
    Also, the patch for cppunit/examples/hierarchy/main.cpp is missing.

    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] Re: [CppUnit] New repository layout...

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

Baptiste Lepilleur wrote:

>     I just obtained the new version of cppunit. I must say the layout is
> much cleaner.
>
>     Yet, the file "estring.h" is missing. I assumed it was supposed to be in
> /cppunit since its an implementation file.
>
>     Two patches are attached, both are based on CVS HEAD:
>         vc6 => compilation for VC++
>         registry => fix the registry bug,  remove it from the test case
> constructors, and the example has been updated not to use the registry
> anymore.
>
>     The patches includes the missing file "estring.h".
>
>     Here is what the vc6 patch to:
>
>     The libraries are generated in /cppunit/lib as
>         cppunit.lib for the release version (optimization turned on, no
> debug info and linking against the static libc).
>         cppunitd.lib for the debug version (no optimization, debug info,
> linking against the dynamic libc).
>
>     The /cppunit/lib directory is automatically created by VC++ at compile
> time, so there is no need to create it in the repository.
>
>     A workspace and project have been created for cppunit in the /cppunit
> directory.
>     A workspace has been created in the /examples directory, and include the
> hierarchy project, and the cppunit project. The hierarchy project depends on
> the cppunit project and the library will be automatically build (so you just
> need to open the examples workspace and run).
>     A workspace and project have been created for the hierarchy example.
>

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

I've had a tendency to forget this myself, see the log4cpp 0.2.4 release for
example :-(

>
>     I have some questions regarding the use of diff & patch:
> diff -Naur cppunit-orig cppunit > cppunit.patch
>     generates the patch, but I need to remove the CVS directories before. Is
> there an simple way to do that ?
>      How do you make patch which contains some binary data (bitmap & icons
> for the graphic test runner).
>
>   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.


>
>   I guess the next step would be:
>   - 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

>
>   - adding the graphic test runner (extensions are required).
>
>     Let me know when this is integrated, so I can test the integrated
> project to check if everything went well.
>

I didn't have a look at the registry patch yet, I'll let you know when I have.

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-vc6.patch.gz
>    cppunit-vc6.patch.gz    Type: application/x-compressed
>                        Encoding: base64
>
>                                 Name: cppunit-registry.patch.gz
>    cppunit-registry.patch.gz    Type: application/x-compressed
>                             Encoding: base64

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

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

Baptiste Lepilleur wrote:

>     I just obtained the new version of cppunit. I must say the layout is
> much cleaner.
>

Thanks, that was the intent. The only change I consider to do next is move
cppunit/* to src/framework and add other dirs under src for extensions.

>
>     Yet, the file "estring.h" is missing. I assumed it was supposed to be in
> /cppunit since its an implementation file.
>

Ah, yes, I see, I somehow managed to make it disappear from CVS during the move
of the other *.h files. Thanks for the notice.

OK, I see I really have to get some sleep now. I'll reply to the rest of the
mail tomorrow, sorry.

Good night,

Bastiaan


>
>     Two patches are attached, both are based on CVS HEAD:
>         vc6 => compilation for VC++
>         registry => fix the registry bug,  remove it from the test case
> constructors, and the example has been updated not to use the registry
> anymore.
>
>     The patches includes the missing file "estring.h".
>

>
>     Here is what the vc6 patch to:
>
>     The libraries are generated in /cppunit/lib as
>         cppunit.lib for the release version (optimization turned on, no
> debug info and linking against the static libc).
>         cppunitd.lib for the debug version (no optimization, debug info,
> linking against the dynamic libc).
>
>     The /cppunit/lib directory is automatically created by VC++ at compile
> time, so there is no need to create it in the repository.
>
>     A workspace and project have been created for cppunit in the /cppunit
> directory.
>     A workspace has been created in the /examples directory, and include the
> hierarchy project, and the cppunit project. The hierarchy project depends on
> the cppunit project and the library will be automatically build (so you just
> need to open the examples workspace and run).
>     A workspace and project have been created for the hierarchy example.
>
>     I have some questions regarding the use of diff & patch:
> diff -Naur cppunit-orig cppunit > cppunit.patch
>     generates the patch, but I need to remove the CVS directories before. Is
> there an simple way to do that ?
>      How do you make patch which contains some binary data (bitmap & icons
> for the graphic test runner).
>
>   How do you apply a patch? understand: what are the magic options ;-) ?
>
>   I guess the next step would be:
>   - adding Michael's Feather framework/extensions back into the project.
> What should be the physical layout ? include/cppunit/extensions ?
>   - adding the graphic test runner (extensions are required).
>
>     Let me know when this is integrated, so I can test the integrated
> project to check if everything went well.
>
>     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-vc6.patch.gz
>    cppunit-vc6.patch.gz    Type: application/x-compressed
>                        Encoding: base64
>
>                                 Name: cppunit-registry.patch.gz
>    cppunit-registry.patch.gz    Type: application/x-compressed
>                             Encoding: base64

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

[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

[Cppunit-devel] TestRegistry... What use for it?

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

    As you may know, I've done the CppUnit Windows Edition. Well, I discussed 
with Bastiaan who have recently taken up the administration of the project and 
we'll be working in integrating things. The windows support will come (this 
version of cppunit is supposed to be cross-platform!).

    When I told him about the TestRegistry bug fix. He told me "the best bug 
fix would be to kill it. I don't see the use of a static registry. JUnit hasn't 
one either anyway."

    Let's not args about the actual implementation, but about the use for it.

    First, here is how the "thing" works:
      1) the TestCase constructor automatically register the test case to the 
TestRegistry.
      2) before running all the test, you're supposed to retreive all the 
registred test using the getAllTests() method and pass them to the test runner.

    Point 1 is definitely a no no, here is why:
       In the traditionnal implementation of your static suite method():
         suite->addTest( new TestCaller<MyTestCase>( "testSomething", 
testSomething ) );

       The problem ? TestCaller creates a new instance of MyTestCase. So what 
happens: the new instance is registered, and the TestCaller, being itself a 
TestCase is also registered!!! You get two tests registered when only one was 
supposed to be! Even worth, in the example, the test case are static variables, 
and guess what happen when the TestRegistry try to delete them !!!
       Conclusion: exterminates the "automatic registration", or at least 
remove it from TestCase and pull it down (I really don't see any use of an 
automatic registration of that form).

    Point 2:
       That's one is actually a nice thing, setting up your test runner look 
like this:
  TestRunner runner;
  TestRegistry registry = TestRegistry::getRegistry()
  runner.addTests( registry.getAllTests() );
  runner.run();

       You do the code once and don't need to update it. The only requierement 
is that you have your tests correctly registered. Of course that is the hard 
part. But suppose it works, it would be rather useful (who never forget to add 
a test either to a suite or to the test runner ?)
       
       The problem is that the registered test would be simple TestCaller, no 
possibility to say run suite XYZ (which would be matching the part your 
refactoring). Well, who said the registered test needed to be TestCaller, you 
can register suite. If only the top level suites would be registered, then 
everything would work fine. How to do that ? I don't know yet, but I'm playing 
with some stuff. I've already implemented a way to have suite for each unit 
test class registered (which is enough for my need at the current time), and I 
will try to extend the idea to build a real hieararchy.

    So my conclusion would be to leave it alone, it may be of use for some, but 
don't make it mandatory. It is a non core "feature" and should not be mandatory.

    Until next time, for the suite auto-registration...
    Baptiste.
     
---
Baptiste Lepilleur <gai...@fr...>
http://gaiacrtn.free.fr/index.html
Language: English, French