[openbeos-build-team] CppUnit

  • From: Tyler Dauwalder <tyler@xxxxxxxxxxxxx>
  • To: openbeos-build-team@xxxxxxxxxxxxx
  • Date: Sun, 07 Jul 2002 14:07:03 -0700

Hi folks,

Well, I've volunteered to merge the two existing CppUnit frameworks 
into one in conjunction with the CVS move and in hopes of encouraging 
the use of unit tests project-wide :-). Here's an overview what I'm 
looking at doing:

App Kit Framework
The App Kit Framework has additions to it that support locking and 
loading of tests via add-ons. 

Locking was done with a BLocker. Since it's class based, I'm thinking 
I'll write up another synchronization class that just uses a 
semaphore, because it doesn't seem right to synchronize the BLocker 
tests with a BLocker, now does it (correct me if I'm wrong :-)?

Loading tests via add-ons was done in favor of not having to relink 
the entire test program every time. Does this really save time 
though? For me at least, linking is what tends to take forever 
(linking the stdc++ lib in specific, I think). If each test is a 
standalone add-on, doesn't it need to be linked separately to all the 
same libs as well? It's really a moot point, though, because I'm 
going to go ahead and support both methods (static and dynamic 
linking) for the sake of flexibility; whichever is actually faster is 
the one I will encourage.

Storage Kit Framework
The Storage Kit Framework has a number of additions to the user 
interface code. Tests for specific classes can be run by name, 
different verbosity levels can be specified (yielding just a few 
lines of summary output, or a few hundred lines of detailed output), 
and simple per-test progress indicatiors (the [1][2][3][4]... output, 
if you've ever tried it out) are all supported. 

I'm going to integrate all those features, plus the ability to 
specify tests by kit (i.e. run all the App Kit tests), and the 
addition of thread-specific per-test progress indicators (i.e. you 
have a test with threads A and B, so you would get progress 
indicators something like [A1][A2][B1][A3][B2]... etc).

I'm also doing the following:

+ Updating to the latest version of CppUnit (v1.8)
+ Updating the existing Storage, Support, and maybe App Kit tests to 
work with the new framework.
+ Probably writing out a little tutorial explaining how to write 
tests for the framework.
+ Offering to consult with anyone who needs help moving their own 
tests over.

R5 vs. OpenBeOS
The other issue we have is that of reference testing, i.e. being able 
to link two separate versions of the test program, one against our 
implementations and one against the R5 implementations, for the sake 
of comparison. The Storage Kit tests currently do this, and Ingo has 
mentioned he may even be able to do it more cleanly now. Certain kits 
will almost certainly have other issues besides just needing to link 
to R5::libbe.so, but I guess we'll cross those bridges when we come 
to them.

So, for those who've made it this far, does this sound reasonable? 
Any requests, objections, or comments?


Other related posts: