RE: Test framework

[Chad Yates]

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

sounds good, go get em.  my driver was just the basics from a cppunit
example, but the CompilerOutputter was a pretty cool "nicety". if you do
clone the cppunit CompilerOutputter class, have it indent the lines after
the compiler line error.  it would make it more readable since a failed test
generates multiple lines 4+ if assert messages, actual, and expected values
are used.

> This is probably a good test for CommandOption and friends. I'll take
> this on if no-one else is particularly interested.

it's all yours (I'm available for testing if you need it)

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

sounds like a good move.

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

I would have to agree the cppunit tree was pretty organized.  I have no
opinion on the naming for the test files, just as long as the word test is
in there somewhere, and that they are consistent.  I've used <Class>Test for
what I've done, but will gladly change to test_<class> if that is the
direction we want to go. cppunit has a contrib directory, is that
conceptually the same thing as common c++'s patches directory?

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

I think some of the headers have become bogged down, and should be broken
down.  I'm of the opinion that for most tests a single class will be
exercised, and so should have it's own file where it makes sense (a unit).
in the cases where your testing the way multiple classes interface that
standard may have to be brushed aside as you'd be testing a composite.  on a
side note, I am willing to re-org the persist.h, engine.cpp, persist.cpp,
digest.h digest.cpp md5.cpp, and sha.cpp files to better break them down
closer to the 1 class equals 1 each of .h/.cpp/.tcc (.tcc is for templates?)
files as appropriate.  the timing would just need to be decided on so I
don't cause trouble for a merge back into cvs (since the contents of the
files would be exploded over multiple other files).  I'm sure other areas
could also benefit also, but these are ones I've become the most familiar
with.

Comments?

,Chad