[interfacekit] Re: Ready, set, go!

I have a thread aware cppunit ready which I think we can use to perform 
tests which need more than one thread (like testing BLocker for 
instance).  Check out:

http://www.windswept-iv.ca/openbeos/CppUnit.zip

When you extract it, go to test/framework in the archive and do a 
"make" to build the cppunit library.  Then go to test/thread and do a 
"make" to build and run an example threaded testcase.  You will see 4 
failures of 6 tests.  That is normal.

The way it works is the following:

test/framework/TestResult.h - I changed the definition of the 
SynchronizationObject class so that it used BLocker to ensure proper 
mutual exclusion while multiple threads try to update the test results.

test/framework/TestThreadLauncher.h - a basic class for launching a 
test in a new thread and controlling that thread.  It is used by the 
ThreadedTestSuite class.

test/framework/ThreadedTestSuite.[cpp|h] - This is the main guts of how 
to do a threaded test.  What I decided to do was to more or less copy 
the code for the TestSuite class and just change the Run() method so 
that all tests added to the suite are started concurrently in seperate 
threads.  What that means is that if you need to test something in 
multiple threads, you need to do a addTest() for each thread you need 
running.

test/thread/ThreadTest.[cpp|h] - This is just a quick sample of a 
simple test of the ThreadedTestSuite class.  All these tests are run 
concurrently.

So, let's imagine I have test1 through test6.  I want test1, 2 and 3 
running at the same time to test concurrency and test4, 5 and 6 running 
concurrently.  However, I want these two sets of three tests run in 
sequence.  To do this, you would

- create a ThreadedTestSuite and add test1 - test3 to it
- create a ThreadedTestSuite and add test4 - test6 to it
- create a TestSuite and add the two ThreadedTestSuite's to it
- run the TestSuite

Do people think the mechanism is OK?  I tried to make the 
ThreadedTestSuite as integrated and consistent with the current CppUnit 
as possible.  The only thing I don't like is modelling each thread 
within a single multithreaded test as individual tests.  It is a bit of 
a stretch, but it was very natural from a code and interface 
standpoint.

Feedback is welcome.  If people think this is a good interface for 
doing threaded tests, I will start changing my existing tests using 
this library.  Thanks.

>Good to hear from you.
>
>I'm inclined to agree with you re. using cppunit with multiple 
threads.  
>Extending cppunit to deal with threads explicitely could be really 
good 
>for the entire OBOS team, so I would definitely encourage you to go 
>ahead with that.
>
>e
>
>Data is not information, and information is not knowledge: knowledge 
is 
>not understanding, and understanding is not wisdom.
>       - Philip Adams

--
Jeremy Rand
jrand@xxxxxxxx

Other related posts: