http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660I second Matt's suggestion for timeout-ing your waits. In our multihreaded tests we use our own Assert.EventWasSet(), and Assert.EventWasNotSet() with default or optional explicit timeouts. http://ayende.com/3837/opening-seams-for-testing#comment3http://ayende.com/3837/opening-seams-for-testing#comment3Fri, 30 Jan 2009 14:42:40 GMTHave you guys played with CHESS yet for unit testing concurrency situations? Microsoft demo'ed it at the PDC. It only works with MSTest at the moment, or standalone exe's, but it's really quite amazing. It tests many likely interleavings of threads by taking control of the thread scheduler. [research.microsoft.com/en-us/projects/chess/](http://research.microsoft.com/en-us/projects/chess/)http://ayende.com/3837/opening-seams-for-testing#comment2http://ayende.com/3837/opening-seams-for-testing#comment2Fri, 30 Jan 2009 04:36:33 GMTI've been working on some code for a socket library we need here that sits on top of the .NET Async sockets. Testing that's been interesting because allowing compression, SSL encryption/decryption and packing/unpacking of our protocol units on background threads is a goal. Not the real issue though. I noticed that you put no timeout on your WaitOne call. I found that sometimes in a multi-threaded environment I could break stuff well enough to never have the wait.Set() called. In that instance the timeout was what stops the suite from stalling forever and allows an error to be logged. Just a thought. http://ayende.com/3837/opening-seams-for-testing#comment1http://ayende.com/3837/opening-seams-for-testing#comment1Fri, 30 Jan 2009 03:48:38 GMT