Re: Test framework; new counter class

[Albert Strasheim]

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