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).
In practice, I usually unit-test my software components in a single threaded environment only. 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.In reply to Re: UnitTesting multi-threaded apps
by eyepopslikeamosquito
in thread UnitTesting multi-threaded apps
by alain_desilets
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |