Re: Test framework; and what should be in 1.1.0

[David Sugar]

At this point, it seems destined for the 1.1 release, and no date has been set 
yet for when that will be made available.  So, no, there is no immediate rush 
:).

It might be worth asserting what things remain to be done for a 1.1 release to 
occur, and for that I would like to suggest the following:

* from the threading perspective, support for pth based ng Linux threading, 
and alternate compile option that can compile for systems that use the pth 
library.

* completion (by me) of ccssl...

* integration of new counter code

* addition of IP6Address classes and ip6 socket support.  (this may actually 
be fairly easy to add...)

* new testing framework

Any comments on this?

On Friday 03 January 2003 02:29, Albert Strasheim wrote:
> Hello,
>
> On Thu, 02 Jan 2003, Chad Yates wrote:
> > I have sent what I have done so far to Albert to compare with his so we
> > can see how they will integrate.  I imagine after he reviews it we can
> > decide how best to integrate it into the library and/or build process.  I
> > wouldn't think we need to rush it into a release, but integrate it
> > progressively stomping any bugs we find along the way.
>
> I've looked over Chad's stuff. Sweet.
>
> I'll have to look my own code over and make sure it plays nice with the
> test factory stuff. I'll do this today.
>
> One thing that needs to get done is to improve the test "driver"
> program. I think the custom TestListener I coded is a step in the right
> direction (gone are the .'s in strange places in the test output).
> Furthermore, we need to add support for a few command line options --
> stuff to run specific tests, skip specific tests, and some other bits
> like outputting "compiler output" for MSVC so that the IDE can send you
> directly to the line where the test failed.
>
> This is probably a good test for CommandOption and friends. I'll take
> this on if no-one else is particularly interested.
>
> Also, we need to decide on a naming convention for the test files. I
> suggest the following:
>
> 1. Move demo/* and test/* to a new "examples" directory.
>
> Reasons: old tests are probably deprecated, but could still serve as
> examples (or be removed once we've integrated them); probably don't want
> _examples_ in the "demo" directory; when I think "demo", I think a big
> monolithic piece of code; CppUnit project put their examples in the
> "examples" directory.
>
> As an aside, the CppUnit source tree is, for me, an example of good
> organisation. I think the Common C++ project should look to emulate
> their source tree layout as far as possible, although we are similar in
> many respects already.
>
> 2. Put the tests in tests/test_<ClassName>.{cpp,h,tcc}.
>
> Reasons: the name is reasonably unambigious, easily grepable, etc.
>
> In the case where you can use a class (templated or not) to test derived
> classes, we could probably add tests for the derived classes to
> test_<BaseClass>.{cpp,h,tcc}, like I did with the UberCounter tests.
>
> A good guideline would probably be: one library header, one set of test
> files, but this breaks down for thread.h and others, since it has about
> 10 classes in there (which should be split up, IMHO).
>
> Comments?
>
> Cheers,
>
> Albert
>
>
> _______________________________________________
> Bug-commoncpp mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/bug-commoncpp