Thanks for you lovely suggestion. As much as I'd love to unit test each and every little thread in a separate test, unfortunately we'd only recently started with automated tests. Time (the lack of) sometimes forces people to enclose existing code in a wrapper to be able to write integration-style tests against legacy and TDD-style for new code. And these contain logic that is responsible for loading things and running things in the right order, and facilitates communication between multiple VM's (cloud-app based app). These not only use multiple threads to monitor multiple queues and other things, but are actually also on physical different machines. These multi-threaded, multi-tiered, and scaling threads and processes need to be working together on the same data (relational) at the same time, and therefor needs to talk to each other so that they don't clash overwrite/supersede/miss each other's updates. A tool like TypeMock Racer would have been useful. Why did TypeMock stop its manufacturing?
Any case, got to go now, need figure out where my multiple-threaded bug is. Oh, wait, I can't. The tools won't let me ;)