UnitTesting a threaded class, avoiding Thread.Sleep() in test?

Basically, you have to apply the Inversion of Control pattern here. Because the code is highly coupled, you are having a problem with testing it.

You should clearly separate all entities and put them against corresponding interfaces. If an entity is used through an interface it is easy to mock it.

public interface ITaskFactory {}public interface IThreadManager {}public interface ICollectorDatabase {}public interface IEventFactory {} public class FileGroupGarbageCollector {  ITaskFactory taskFactory;  IThreadManager threadManager;  ICollectorDatabase database;  IEventFactory events;  FileGroupGarbageCollector (ITaskFactory taskFactory,    IThreadManager threadManager, ICollectorDatabase database,    IEventFactory events)  {     // init members..  }}

As soon as all dependencies are isolated, FileGroupGarbageCollector does not use any of them directly. In your test, the IEventFactory mock will return Event, that would do just nothing if WaitOne method is called. So, you don't need any sleeps in your code.

Go and find as much as you can on - Mocking, Inversion of Control, Dependency Injection patterns.

Thread.Sleep is a hallmark of a poorly-designed program. However, it can be quite useful in unit tests.

The only other option is to change the usage of "time". The Rx team has done some great work in this area; their schedulers are all testable. But that doesn't help out your particular situation (unless you convert to the Rx schedulers).

If you really want to avoid Thread.Sleep in your unit tests, then you'll need to abstract out the parts that depend on time (either using Inversion of Control or an interception library like Microsoft Moles); the problem is that it's very hard to create a complete and consistent abstraction of "time". Personally, I don't lose sleep over having Thread.Sleep in my unit tests.