FreeLists / openbeosstorage / [openbeosstorage] Unit Testing Framework

["Tyler Dauwalder" <tyler@xxxxxxxxxxxxx>]

Per som suggestions from Simon, I think it would be
good for us to have someone in charge of the unit 
testing framework.  Your duties will be to design,
implement, and maintain the framework of unit testing 
that we'll use. 

We'll each still be responsible for writing our own tests
while we're developing, but they'll be implemented as part 
of the framework you design.

I don't care if it's just a big main() function, or integration
with some sort of testing system like CppUnit, or even
if you use something like Python to manage a set of 
smaller test programs. Whatever works. I'll leave it up 
to you to decide what you think is necessary and
sufficient. The few requirements I'll have are:

----------------------------------------------------------------------
1. We must be able specify which parts of the kit are
to be tested on a given run. At the very least, I want
to be able to specify "test everything" or "test class X".
Finer grained control might be nice, but it's not a
requirement.

2. It must be relatively straightforward to add new tests
for new classes. I.e. the framework needs to be easily
and cleanly extensible. 
----------------------------------------------------------------------

Some suggestions for things that might be nice to have:

----------------------------------------------------------------------
I. A standard format for output of test results might be
handy. I.e. formalize what types of results are going to
be returned from a test, and how they are to be displayed.
This would make it easier to write scripts or programs to
read through the test output and say "A, B, and C failed,
everything else worked" or something to that degree.

Alternately, that sort of summary functionality might want 
to be an inherent part of the framework design. Your call.

II. I think it would probably best for the base framework to be
command line based as a minimum. You can always write a
GUI on top of or along side of the command line interface. 
However, having a command line interface available means 
the testing can be more easily integrated into shell scripts, etc.
----------------------------------------------------------------------

I'll leave the position open for a volunteer for a couple
of days, and if I don't hear anything, I'll probably just
assign somebody.

If a couple of you want to work on it together, that'd be
fine too, but at least two of us are going to keep working
on the kernel interface.

Also, if any of you can think of anything that should be
a requirement for the test framework, or have suggestions
for things you think might be useful, please post them to
the list. Thanks! :-)

-Tyler