c# multithreading unit test

Question

I'm looking for some advice on writing unit tests for multi-threading in C#. Specifically, I want to check that an object is being locked correctly. However, in order to test this I need to assert against that object, which may have changed before the assert(s) are implemented (with the lock being released, another thread may change the object).

Using AutoResetEvent I have been able to control the flow in the unit test side, allowing me to effectively emulate the lock in the tested object. The issue with this is that I no longer need the lock for the test to pass.

What I'd like is to have a test that passes with the lock in and fails with it out.

Obviously, this is a simplified example. It's also .Net 4, so there is no async and await option (although if that would help, changing could be an option).

Suggestions welcome. Thanks.

Below is example code:

    public class BasicClass
    {
        public int Val 
        { 
            get { lock (lockingObject) { return val; } } 
            private set { lock (lockingObject) { val = value; } } 
        }
        private int val;

        public BasicClass(int val = -1)
        {
            Val = val;
        }

        public void SetValue(int val)
        {
            Val = val;
        }
        private object lockingObject = new object();
    }

This is the (NUnit) unit test:

    [Test]
    public void BasicClassTest()
    {
        for (int repeat = 0; repeat < 1000; repeat++) // Purely for dev testing and can get away with as no SetUp/TearDown
        {
            BasicClass b = new BasicClass();

            int taskCount = 10;
            Task[] tasks = new Task[taskCount];

            var taskControl = new AutoResetEvent(false);
            var resultControl = new AutoResetEvent(false);
            int expected = -1;

            for (int i = 0; i < taskCount; i++)
            {
                int temp = i;
                tasks[temp] = new Task(() =>
                    {
                        taskControl.WaitOne(); // Hold there here until set
                        b.SetValue(temp);
                        expected = temp;
                        resultControl.Set();   // Allows asserts to be processed.
                    });
            }

            // Start each task
            foreach (var t in tasks)
                t.Start();

            // Assert results as tasks finish.
            for (int i = 0; i < taskCount; i++)
            {
                taskControl.Set();       // Unblock, allow one thread to proceed.
                resultControl.WaitOne(); // Wait for a task to set a expected value
                Assert.That(b.Val, Is.EqualTo(expected));
                Console.WriteLine("b.Val = {0}, expected = {1}", b.Val, expected); // Output values to ensure they are changing
            }

            // Wait for all tasks to finish, but not forever.
            Task.WaitAll(tasks, 1000);
        }
    }

Answer 1

As for other system functions like DateTime.Now, I prefer to abstract threading functions like sleep, mutex, signals and so on (yes, I know there are libraries for DateTime.Now and other system functions, but I think to abstract it is a better way).

So you end up with a kind of IThreadind interface with methods to Sleep and so on. The disadvantage is, that you can't use the handy lock statement in this case. You could have a method Lock(object) that returns you an IDisposable that you can use with the "using" statement, to get nearly the same comfort.

using(threading.Lock(lockObject))
{
...
}

Now you can Create a real implementation with the real functions and a Mock for your unit tests which is injected. So you could for example for your tests shortcut any sleep call to e few ms in order to speed up your tests. And you can verify that all functions where called that you expected.

Sounds like a lot of work? Think over, how many time you will spend to debug some nasty threading issue which from time to time crashes your production system with your customer running amok.