Unit-testing threads?

Question

I just need to unit test some methods like this:

public void start()
{
    myThread.Start();
}

public void stop()
{
    myThread.Abort();
}

How can i do that? I may call start method and check for IsAlive==true but then thread keeps working in background and calls its own method. Another way is I call start and then stop immediately but it's not neat cause it would be like I'm testing two things. It's so simple but arghh!

Answer 1

The trick is to separate the asynchronous behavior from your logic. Observe that your actual logic is synchronous, and that the asynchronous part is simply some "waiting time" in between.

The book xUnit Test Patterns describes it well. It's even a pattern - Humble Object . It's explained there way better than I can.

Answer 2

Use thread synchronization and wait handles to wait on running threads.

Thread Synchronization (C# Programming Guide)

Answer 3

It's a good idea to make things that would be timing-dependent be synchronous for the purposes of testing. (Indeed it's a good idea to localize timing-dependent interactions even in non-testing use.)

If you really just want to check that these methods do start and stop a thread, I would insert a dummy object myThread that provides those methods but does not actually start a thread, or a thread whose code will just sit and wait without doing anything. Then you can record that it's started, and stopped, without worrying about the complexity of what your real thread will do.

Perhaps your situation is more complex than just checking the thread is started? It might help if you posted a slightly larger example of the kind of thing you want to test.

Answer 4

I agree with BnWasteland that for the given code example the only thing one can test is that System.Threading.Thread.Start and System.Threading.Thread.Abort work properly. So it would be reasonable to assume that they are and focus on Application's own code. Then you have two domains:

1) The code of actual task that executes inside the thread. This can be tested in a normal unit-test.

2) Make sure the multithreaded infrastructure works as expected.

(2) tends more to Integration testing category but no one forbids using Unit-tesitng framework for this. And in this case it is fine to do Start/Stop and even do this several times with some randomized workloads just to make sure the system behaves and gets the work done. This obviously goes into "longer-running" test suit which you wouldn't necessary want to execute at every check-in.

Answer 5

Why do you need to unit test those methods? What are you trying to verify? Would other tests break if the thing you are trying to verify isn't true? (IE is it covered by other tests?)

If not, you can get into semaphores, and have your unit test ensure that the thread started up before a given timeout, but I just don't think it's an extremely valuable test in the end. It wouldn't increase my confidence much.