Simon on Software

The BackgroundWorker class is a fantastically simple way of firing off long-running tasks without the complexities associated with threading. However, tests that exercise code that uses a BackgroundWorker may not behave as desired. Unit tests run synchronously, and will not wait for the BackgroundWorker to complete. This article shows an approach which resolves this limitation.

[TestFixture]
    public class TestClass
    {
        [Test]
        public void TestLongRunningOperationCompletesSuccessfullyBadImplementation()
        {
            SomeLongRunningOperation task = new SomeLongRunningOperation();
            task.DoStuff();
            Assert.AreEqual(true, task.IsHit);
        }
    }

    public class SomeLongRunningOperation
    {
        private bool _isHit;

        public bool IsHit
        {
            get { return _isHit; }
        }

        public void DoStuff()
        {
            BackgroundWorker worker = new BackgroundWorker();
            worker.DoWork += delegate
            {
                _isHit = true;
            };
            worker.RunWorkerAsync();
        }
    }

This test will never pass as the unit test runner runs synchronously, so it will not wait for the background work to complete, and the assertion will never be met. Of course, we could put a Thread.Sleep in the test to wait for the task to complete, but this is brittle and as choosing an appropriate time is difficult it will make the test run more slowly.

Instead, we can create a wrapper around the BackgroundWorker class, and an implementation that runs synchronously just for testing.

public class BackgroundWorkerWrapper : IBackgroundWorker
    {
        readonly BackgroundWorker _worker = new BackgroundWorker();

        public void RunWorkerAsync()
        {
            _worker.RunWorkerAsync();
        }

        public void RunWorkerAsync(object args)
        {
            _worker.RunWorkerAsync(args);
        }

        public event RunWorkerCompletedEventHandler RunWorkerCompleted
        {
            add { _worker.RunWorkerCompleted += value; }
            remove { _worker.RunWorkerCompleted -= value; }
        }

        public event DoWorkEventHandler DoWork
        {
            add { _worker.DoWork += value; }
            remove { _worker.DoWork -= value; }
        }

        public bool IsBusy
        {
            get { return _worker.IsBusy; }
        }
    }

    public class SynchronousBackgroundWorker : IBackgroundWorker
    {
        public void RunWorkerAsync()
        {
            DoWorkEventArgs args = new DoWorkEventArgs(null);
            RunWorkerSync(args);
        }

        private void RunWorkerSync(DoWorkEventArgs args)
        {
            DoWork.Invoke(this, args);
            RunWorkerCompleted.Invoke(this, new RunWorkerCompletedEventArgs(args.Result, null, false));
        }

        public void RunWorkerAsync(object arguments)
        {
            DoWorkEventArgs args = new DoWorkEventArgs(arguments);
            RunWorkerSync(args);
        }

        public event RunWorkerCompletedEventHandler RunWorkerCompleted = delegate { };

        public event DoWorkEventHandler DoWork = delegate { };

        public bool IsBusy
        {
            get { return false; }
        }
    }

    public class BackgroundWorkerFactory : IBackgroundWorkerFactory
    {
        public IBackgroundWorker GetWorker()
        {
            return IoC.Resolve();
        }
    }

    public class SynchronousBackgroundWorkerFactory : IBackgroundWorkerFactory
    {
        public IBackgroundWorker GetWorker()
        {
            return new SynchronousBackgroundWorker ();
        }
    }

    public interface IBackgroundWorkerFactory
    {
        IBackgroundWorker GetWorker();
    }

    public interface IBackgroundWorker
    {
        void RunWorkerAsync();
        void RunWorkerAsync(object arguments);
        event RunWorkerCompletedEventHandler RunWorkerCompleted;
        event DoWorkEventHandler DoWork;
        bool IsBusy { get;}
    }

Now we can modify the class that performs the long-running operation to have a backgroundworker factory injected. The production code can pull out the “real” factory via the DI container.

[TestFixture]
    public class TestClass
    {
        [Test]
        public void TestLongRunningOperationCompletesSuccessfully()
        {
            SomeLongRunningOperation task = new SomeLongRunningOperation(new SynchronousBackgroundWorkerFactory());
            task.DoStuff();
            Assert.AreEqual(true, task.IsHit);
        }
    }

    public class SomeLongRunningOperation
    {
        private readonly IBackgroundWorkerFactory _backgroundWorkerFactory;

        private bool _isHit;

        public SomeLongRunningOperation(IBackgroundWorkerFactory backgroundWorkerFactory)
        {
            _backgroundWorkerFactory = backgroundWorkerFactory;
        }

        public bool IsHit
        {
            get { return _isHit; }
        }

        public void DoStuff()
        {
            IBackgroundWorker worker =  _backgroundWorkerFactory.GetWorker();

            worker.DoWork += delegate
                                 {
                                     _isHit = true;
                                 };
            worker.RunWorkerAsync();
        }
    }

Is there any good reason to do this? I say no. It makes your code run slower, and with tricky to debug errors. Throw exceptions early – then they will be dealt with during development, rather than in production.

We found today that we had some errors in some of our data access code that was pulling data out of a datarow and into an object.

We essentially had code that performed the following:

try
{
   object data = dataRow[ColumnName];
   return data;
}
catch (Exception ex)
{
   Logger.Error(string.Format("Could not retrieve Column value with column name - {0}\n.{1}", ColumnName, ex));
}

This led to our integration tests passing, as they are not able to see that an exception is raised, and the stored procedure needs to be updated with the relevant Column.

Far better would be:

catch (Exception ex)
{
   Logger.Error(string.Format("Could not retrieve Column value with column name - {0}\n.{1}", ColumnName, ex));
   throw;
}

This logs the exception as per the original, but also throws the exception, and voila, our integration test will catch that.

And yes, the fact that we are using Stored Procedures is not ideal either.

OK, so it is my second post, and things are going downhill already.

Meta-Blogging. The first rule of blogging is no meta-blogging.

Someone might find this useful though.

I just figured out how to get nice code formatting with little effort, just by installing a WordPress plugin. This will syntax highlight c#, sql, java, html amongst others.

All you need to do to is search for “Google Syntax Highlighter for WordPress” under Add New Plugin.

Activate the plugin.

This documents how to use the code from within a pre or textarea tag.

Console.WriteLine("That's pretty simple");