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

I'm trying to figure out the best way to unit test this class:

public class FileGroupGarbageCollector
{
    private Task _task;

    private readonly AutoResetEvent _event = new AutoResetEvent(false);

    public void Start()
    {
        _task = Task.Factory.StartNew(StartCollecting);

    }

    public void Stop()
    {
        _event.Set();
    }

    private void StartCollecting()
    {
        do
        {
            Process();
        }
        while (!_event.WaitOne(60000, false));            
    }

    private void Process()
    {
        /* do some work to the database and file system */
    }
}

It's not supposed to be the most well formed class, just trying to figure out something!

I then have a unit test where I want to start and then stop the service, asserting the the private 'Processs' method did something to the database or filesystem.

My unit test is as follows (nunit):

    [Test]
    public void TestStart()
    {
        var fg = new FileGroupGarbageCollector(30000);

        fg.Start();

        Thread.Sleep(5000); // i hate this!

        fg.Stop();

        // assert it did what i wanted it to do!
    }

Is there any way or any nice pattern that can be used here so I can avoid Thread.Sleep()? I hate the idea of sleeping in a unit test (let alone in production code), but I refuse to just test private functionality! I want to test the public interface of this class.

Any answers are greatly appreciated :)

UPDATE AFTER ANSWER

I went with the IoC way of things and it works really nicely :)

public interface IEventFactory { IEvent Create(); }

public interface IEvent
{
    bool WaitOne(int timeout);
    vo开发者_运维知识库id Set();
}

Then my mock objects (using Moq):

 var mockEvent = new Mock<IEvent>();
 var mockEventFactory = new Mock<IEventFactory>();

 mockEvent.Setup(x => x.WaitOne(It.IsAny<int>())).Returns(true);
 mockEvent.Setup(x => x.Set());

 mockEventFactory.Setup(x => x.Create()).Returns(mockEvent.Object);

So instantly a call to IEvent.WaitOne() returns true and exits, so no need for the Thread.Sleep()!

:)

---

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.