It's well known that unit testing and multi-threading don't mix very well. This is still an active area of research. I touched on this topic recently in Nobody Expects the Agile Imposition (Part VI): Architecture (see the "Unit Testing Concurrent Code" and "Testing Concurrent Software References" sections).
So far, I haven't found it hard to write tests to verify the multi-threaded parts. For example, I have a class called JobQueue which acts as a shared object between a Boss thread and a Worker thread. I have been able to write tests to verify that two separate thereads can indeed use this class to communicate in a Boss-Worker mode.
My problem is that I can't run the JobQueueTest in the same run as some other tests that use non thread-safe modules.
I guess I could write a shell script that starts two processes, one to test the thread-safe bits, and one to test the non-thread safe bits.
In practice, I usually unit-test my software components
in a single threaded environment only.
This of course, assumes that your program can run in both modes: multi-threaded and single threaded. This makes the design more complex, but I guess it's a good idea anyway, given that perl threads are still somewhat bleeding edge (in other words, it would good for me to make sure that I can fallback on single threading if it turns out that multi-threading is causing too many problems). I think it should be possible for me to do that.
For flushing out
concurrency bugs in multi-threaded code, the most
effective (if crude) technique I've found is good tracing
code at just the right places, combined with
understanding and reasoning about the multi-threaded code
and performing experiments. One especially useful
experiment is to add "jiggle points" at critical places
in your concurrent code and have the jiggle point either
do nothing, yield, or sleep for a short interval. There
are more sophisticated tools available, for example IBM's
ConTest, that use this approach.
Can you elaborate on the jiggle point technique?