How to Unit Test BackgroundWorker + PRISM InteractionRequest?

Question

I have a reoccurring pattern in my WPF MVVM applications that has the following structure.

public class MyViewModel : NotificationObject
{
    private readonly IService _DoSomethingService;

    private bool _IsBusy;
    public bool IsBusy
    {
        get { return _IsBusy; }
        set
        {
            if (_IsBusy != value)
            (
                _IsBusy = value;
                RaisePropertyChanged(() => IsBusy);
            )
        }
    }

    public ICommand DisplayInputDialogCommand { get; private set; }
    public InteractionRequest<Notification> Error_InteractionRequest { get; private set; }
    public InteractionRequest<Confirmation> GetInput_InteractionRequest { get; private set; }

    // ctor
    public MyViewModel(IService service)
    {
        _DoSomethingService = service;

        DisplayInputDialogCommand  = new DelegateCommand(DisplayInputDialog);
        Error_InteractionRequest = new InteractionRequest<Notification>();
        Input_InteractionRequest = new InteractionRequest<Confirmation>();
    }

    private void DisplayInputDialog()
    {
        Input_InteractionRequest.Raise(
            new Confirmation() {
                Title = "Please provide input...",
                Content = new InputViewModel()
            },
            ProcessInput
        );
    }

    private void ProcessInput(Confirmation context)
    {
        if (context.Confirmed)
        {
            IsBusy = true;

            BackgroundWorker bg = new BackgroundWorker();
            bg.DoWork += new DoWorkEventHandler(DoSomethingWorker_DoWork);
            bg.RunWorkerCompleted += new RunWorkerCompletedEventHandler(DoSomethingWorker_RunWorkerCompleted);
            bg.RunWorkerAsync();
        }
    }

    private void DoSomethingWorker_DoWork(object sender, DoWorkEventArgs e)
    {
        _DoSomethingService.DoSomething();
    }

    private void DoSomethingWorker_RunWorkerCompleted(object sender, RunWorkerCompletedEventArgs e)
    {
        IsBusy = false;

        if (e.Error != null)
        {
            Error_InteractionRequest.Raise(
                new Confirmation() {
                    Title = "Error",
                    Content = e.Error.Message
                }
            );
        }
    }
}

Essentially, the pattern describes a dialog oriented workflow that allows the user to initiate (and provide input to) a long running operation without locking the UI. A concrete example of this pattern might be a "Save As..." operation where the user clicks a "Save As..." button, then keys in a text value for filename in a popup dialog, then clicks the dialog OK button, then watches a spin animation while their data is saved under the specified filename.

In the provided code example, initiating this workflow will perform the following operations.

1. Raise the Input_InteractionRequest Raised event to display a dialog in the UI for the purpose of collecting user input.

2. Invoke the ProcessInput callback (triggered when the user completes the dialog).

3. Check the Confirmed property of the InteractionRequest context to determine if the dialog was confirmed or canceled.

4. If confirmed...

   1. Set the IsBusy flag.

   2. Start a BackgroundWorker to perform the long running _DoSomethingService.DoSomething() operation.

   3. Unset the IsBusy flag.

   4. If an error occurred in DoSomething_DoWork, raise the Error_InteractionRequest Raised event to display a message box in the UI for the purpose of informing the user that the operation was not successful.

I would like to maximize unit testing coverage for this pattern, but I'm not quite sure how to approach it. I would like to avoid unit testing non-public members directly since the specific implementation of this pattern could change over time and in fact varies from instance to instance throughout my applications. I have considered the following options, but none of them seem appropriate.

1. Replace BackgroundWorker with IBackgroundWorker and inject it via ctor. Use a synchronous IBackgroundWorker during tests to ensure that unit tests do not complete before DoWork/RunWorkerCompleted methods are called. This would require a lot of refactoring and does not address testing the InteractionRequest callback either.

2. Use System.Threading.Thread.Sleep(int) to allow the BackgroundWorker operation to complete before the assertion stage. I don't like this because it is slow and I still don't know how to test code paths in the InteractionRequest callback.

3. Refactor the BackgroundWorker methods and InteractionRequest callback into Humble Objects that can be syncronously and independently tested. This seems promising, but structuring it has me stumped.

4. Unit test DoSomethingWorker_DoWork, DoSomethingWorker_RunWorkerCompleted, and ProcessInput synchronously and independently. This would give me the coverage I need, but I would be testing against a specific implementation rather than the public interface.

What is the best way to unit test and/or refactor the above pattern to provide maximum code coverage?

Answer 1

EDIT: See update below for simpler alternative (.NET 4.0+ only).

This pattern can be easily tested by abstracting the mechanics of BackgroundWorker behind an interface and then testing against that interface as described in this question. Once the quirks of the BackgroundWorker have been obscured behind an interface, testing the InteractionRequest becomes straightforward.

This is the interface I decided to use.

public interface IDelegateWorker
{
    void Start<TInput, TResult>(Func<TInput, TResult> onStart, Action<TResult> onComplete, TInput parm);
}

This interface exposes a single Start method that accepts the following parameters.

1. Func<TInput, TResult> onStart - Comparable to BackgroundWorker.DoWork. This is where you would perform the primary work of your background operation. This delegate should accept a single parameter of type TInput and return a value of type TResult which should be passed on to the onComplete delegate.

2. Action<TResult> onComplete - Comparable to BackgroundWorker.RunWorkerCompleted. This delegate will be invoked after the onStart delegate completes. This is where you would perform any post-processing work. This delegate should accept a single parameter of type TResult.

3. TInput parm - The initial value to pass into the onStart delegate (or null if the onStart delegate does not require input). Comparable to passing an argument value to the Backgroundworker.RunWorkerAsync(object argument) method.

You can then use dependency injection to replace the BackgroundWorker instance with an instance of IDelegateWorker. For example, the rewritten MyViewModel now looks like this.

public class MyViewModel : NotificationObject
{
    // Dependencies
    private readonly IService _doSomethingService;
    private readonly IDelegateWorker _delegateWorker; // new

    private bool _IsBusy;
    public bool IsBusy
    {
        get { return _IsBusy; }
        set
        {
            if (_IsBusy != value)
            {
                _IsBusy = value;
                RaisePropertyChanged(() => IsBusy);
            }
        }
    }

    public ICommand DisplayInputDialogCommand { get; private set; }
    public InteractionRequest<Notification> ErrorDialogInteractionRequest { get; private set; }
    public InteractionRequest<Confirmation> InputDialogInteractionRequest { get; private set; }

    // ctor
    public MyViewModel(IService service, IDelegateWorker delegateWorker /* new */)
    {
        _doSomethingService = service;
        _delegateWorker = delegateWorker; // new

        DisplayInputDialogCommand = new DelegateCommand(DisplayInputDialog);
        ErrorDialogInteractionRequest = new InteractionRequest<Notification>();
        InputDialogInteractionRequest = new InteractionRequest<Confirmation>();
    }

    private void DisplayInputDialog()
    {
        InputDialogInteractionRequest.Raise(
            new Confirmation()
            {
                Title = "Please provide input...",
                Content = new DialogContentViewModel()
            },
            ProcessInput
        );
    }

    private void ProcessInput(Confirmation context)
    {
        if (context.Confirmed)
        {
            IsBusy = true;

            // New - BackgroundWorker now abstracted behind IDelegateWorker interface.
            _delegateWorker.Start<object, TaskResult<object>>(
                    ProcessInput_onStart,
                    ProcessInput_onComplete,
                    null
                );
        }
    }

    private TaskResult<object> ProcessInput_onStart(object parm)
    {
        TaskResult<object> result = new TaskResult<object>();
        try
        {
            result.Result = _doSomethingService.DoSomething();
        }
        catch (Exception ex)
        {
            result.Error = ex;
        }
        return result;
    }

    private void ProcessInput_onComplete(TaskResult<object> tr)
    {
        IsBusy = false;

        if (tr.Error != null)
        {
            ErrorDialogInteractionRequest.Raise(
                new Confirmation()
                {
                    Title = "Error",
                    Content = tr.Error.Message
                }
            );
        }
    }

    // Helper Class
    public class TaskResult<T>
    {
        public Exception Error;
        public T Result;
    }
}

This technique allows you to avoid the quirks of the BackgroundWorker class by injecting a syncronous (or mock) implementation of IDelegateWorker into MyViewModel when testing and an asyncronous implementation for production. For example, you could use this implementation when testing.

public class DelegateWorker : IDelegateWorker
{
    public void Start<TInput, TResult>(Func<TInput, TResult> onStart, Action<TResult> onComplete, TInput parm)
    {
        TResult result = default(TResult);

        if (onStart != null)
            result = onStart(parm);

        if (onComplete != null)
            onComplete(result);
    }
}

And you could use this implementation for production.

public class ASyncDelegateWorker : IDelegateWorker
{
    public void Start<TInput, TResult>(Func<TInput, TResult> onStart, Action<TResult> onComplete, TInput parm)
    {
        BackgroundWorker bg = new BackgroundWorker();
        bg.DoWork += (s, e) =>
        {
            if (onStart != null)
                e.Result = onStart((TInput)e.Argument);
        };

        bg.RunWorkerCompleted += (s, e) =>
        {
            if (onComplete != null)
                onComplete((TResult)e.Result);
        };

        bg.RunWorkerAsync(parm);
    }
}

With this infrastructure in place, you should be able to test all aspects of your InteractionRequest as follows. Note that I am using MSTest and Moq and have achieved 100% coverage according to the Visual Studio Code Coverage tool although that number is somewhat suspect to me.

[TestClass()]
public class MyViewModelTest
{
    [TestMethod()]
    public void DisplayInputDialogCommand_OnExecute_ShowsDialog()
    {
        // Arrange
        Mock<IService> mockService = new Mock<IService>();
        Mock<IDelegateWorker> mockWorker = new Mock<IDelegateWorker>();
        MyViewModel vm = new MyViewModel(mockService.Object, mockWorker.Object);
        InteractionRequestTestHelper<Confirmation> irHelper
            = new InteractionRequestTestHelper<Confirmation>(vm.InputDialogInteractionRequest);

        // Act
        vm.DisplayInputDialogCommand.Execute(null);

        // Assert
        Assert.IsTrue(irHelper.RequestRaised);
    }

    [TestMethod()]
    public void DisplayInputDialogCommand_OnExecute_DialogHasCorrectTitle()
    {
        // Arrange
        const string INPUT_DIALOG_TITLE = "Please provide input...";
        Mock<IService> mockService = new Mock<IService>();
        Mock<IDelegateWorker> mockWorker = new Mock<IDelegateWorker>();
        MyViewModel vm = new MyViewModel(mockService.Object, mockWorker.Object);
        InteractionRequestTestHelper<Confirmation> irHelper
            = new InteractionRequestTestHelper<Confirmation>(vm.InputDialogInteractionRequest);

        // Act
        vm.DisplayInputDialogCommand.Execute(null);

        // Assert
        Assert.AreEqual(irHelper.Title, INPUT_DIALOG_TITLE);
    }

    [TestMethod()]
    public void DisplayInputDialogCommand_OnExecute_SetsIsBusyWhenDialogConfirmed()
    {
        // Arrange
        Mock<IService> mockService = new Mock<IService>();
        Mock<IDelegateWorker> mockWorker = new Mock<IDelegateWorker>();
        MyViewModel vm = new MyViewModel(mockService.Object, mockWorker.Object);
        vm.InputDialogInteractionRequest.Raised += (s, e) =>
        {
            Confirmation context = e.Context as Confirmation;
            context.Confirmed = true;
            e.Callback();
        };

        // Act
        vm.DisplayInputDialogCommand.Execute(null);

        // Assert
        Assert.IsTrue(vm.IsBusy);
    }

    [TestMethod()]
    public void DisplayInputDialogCommand_OnExecute_CallsDoSomethingWhenDialogConfirmed()
    {
        // Arrange
        Mock<IService> mockService = new Mock<IService>();
        IDelegateWorker worker = new DelegateWorker();
        MyViewModel vm = new MyViewModel(mockService.Object, worker);
        vm.InputDialogInteractionRequest.Raised += (s, e) =>
        {
            Confirmation context = e.Context as Confirmation;
            context.Confirmed = true;
            e.Callback();
        };

        // Act
        vm.DisplayInputDialogCommand.Execute(null);

        // Assert
        mockService.Verify(s => s.DoSomething(), Times.Once());
    }

    [TestMethod()]
    public void DisplayInputDialogCommand_OnExecute_ClearsIsBusyWhenDone()
    {
        // Arrange
        Mock<IService> mockService = new Mock<IService>();
        IDelegateWorker worker = new DelegateWorker();
        MyViewModel vm = new MyViewModel(mockService.Object, worker);
        vm.InputDialogInteractionRequest.Raised += (s, e) =>
        {
            Confirmation context = e.Context as Confirmation;
            context.Confirmed = true;
            e.Callback();
        };

        // Act
        vm.DisplayInputDialogCommand.Execute(null);

        // Assert
        Assert.IsFalse(vm.IsBusy);
    }

    [TestMethod()]
    public void DisplayInputDialogCommand_OnExecuteThrowsError_ShowsErrorDialog()
    {
        // Arrange
        Mock<IService> mockService = new Mock<IService>();
        mockService.Setup(s => s.DoSomething()).Throws(new Exception());
        DelegateWorker worker = new DelegateWorker();
        MyViewModel vm = new MyViewModel(mockService.Object, worker);
        vm.InputDialogInteractionRequest.Raised += (s, e) =>
        {
            Confirmation context = e.Context as Confirmation;
            context.Confirmed = true;
            e.Callback();
        };
        InteractionRequestTestHelper<Notification> irHelper
            = new InteractionRequestTestHelper<Notification>(vm.ErrorDialogInteractionRequest);

        // Act
        vm.DisplayInputDialogCommand.Execute(null);

        // Assert
        Assert.IsTrue(irHelper.RequestRaised);
    }

    [TestMethod()]
    public void DisplayInputDialogCommand_OnExecuteThrowsError_ShowsErrorDialogWithCorrectTitle()
    {
        // Arrange
        const string ERROR_TITLE = "Error";
        Mock<IService> mockService = new Mock<IService>();
        mockService.Setup(s => s.DoSomething()).Throws(new Exception());
        DelegateWorker worker = new DelegateWorker();
        MyViewModel vm = new MyViewModel(mockService.Object, worker);
        vm.InputDialogInteractionRequest.Raised += (s, e) =>
        {
            Confirmation context = e.Context as Confirmation;
            context.Confirmed = true;
            e.Callback();
        };
        InteractionRequestTestHelper<Notification> irHelper
            = new InteractionRequestTestHelper<Notification>(vm.ErrorDialogInteractionRequest);

        // Act
        vm.DisplayInputDialogCommand.Execute(null);

        // Assert
        Assert.AreEqual(irHelper.Title, ERROR_TITLE);
    }

    [TestMethod()]
    public void DisplayInputDialogCommand_OnExecuteThrowsError_ShowsErrorDialogWithCorrectErrorMessage()
    {
        // Arrange
        const string ERROR_MESSAGE_TEXT = "do something failed";
        Mock<IService> mockService = new Mock<IService>();
        mockService.Setup(s => s.DoSomething()).Throws(new Exception(ERROR_MESSAGE_TEXT));
        DelegateWorker worker = new DelegateWorker();
        MyViewModel vm = new MyViewModel(mockService.Object, worker);
        vm.InputDialogInteractionRequest.Raised += (s, e) =>
        {
            Confirmation context = e.Context as Confirmation;
            context.Confirmed = true;
            e.Callback();
        };
        InteractionRequestTestHelper<Notification> irHelper
            = new InteractionRequestTestHelper<Notification>(vm.ErrorDialogInteractionRequest);

        // Act
        vm.DisplayInputDialogCommand.Execute(null);

        // Assert
        Assert.AreEqual((string)irHelper.Content, ERROR_MESSAGE_TEXT);
    }

    // Helper Class
    public class InteractionRequestTestHelper<T> where T : Notification
    {
        public bool RequestRaised { get; private set; }
        public string Title { get; private set; }
        public object Content { get; private set; }

        public InteractionRequestTestHelper(InteractionRequest<T> request)
        {
            request.Raised += new EventHandler<InteractionRequestedEventArgs>(
                (s, e) =>
                {
                    RequestRaised = true;
                    Title = e.Context.Title;
                    Content = e.Context.Content;
                });
        }
    }
}

Notes:

1. Another option is to use the commercial version of the TypeMock isolation (mocking) framework. This framework is ideal for legacy code or code that is otherwise not well suited for unit testing. TypeMock allows you to mock just about anything. I will not go into the specifics of how this could be used for the question at hand, but it is still worth pointing out that it is a valid option.

2. In .NET 4.5 use of BackgroundWorker is deprecated in favor of the async/await pattern. The use of the IDelegateWorker (or some similar) interface as described above allows your entire project to migrate to the async/await pattern without the need to modify a single ViewModel.

Update:

After implementing the technique described above, I discovered a simpler approach for .NET 4.0 or better. To unit test an asynchronous process, you need some way to detect when that process is complete or you need to be able to run that process synchronously during tests.

Microsoft introduced the Task Parallel Library (TPL) in .NET 4.0. This library provides a rich set of tools for performing asynchronous operations that go far beyond the capabilities of the BackgroundWorker class. The best way to implement an asynchronous operation is to use the TPL and then return a Task from your method under test. Unit testing an asynchronous operation implemented in this way is then trivial.

[TestMethod]
public void RunATest()
{
    // Assert.
    var sut = new MyClass();

    // Act.
    sut.DoSomethingAsync().Wait();

    // Assert.
    Assert.IsTrue(sut.SomethingHappened);
}

If it is impossible or impractical to expose the task to your unit test, then the next best option is to override the way that tasks are scheduled. By default tasks are scheduled to run asynchronously on the ThreadPool. You can override this behavior by specifying a custom scheduler in code. For example, the following code will run a task using the UI thread.

Task.Factory.StartNew(
    () => DoSomething(),
    TaskScheduler.FromCurrentSynchronizationContext());

To implement this in a way that is unit testable, pass the task scheduler in using Dependency Injection. Your unit tests can then pass in a task scheduler that performs the operation synchronously on the current thread and your production application will pass in a task scheduler that runs the tasks asynchronously on the ThreadPool.

You can even go a step further and eliminate the dependency injection by overriding the default task scheduler using reflection. This makes your unit tests a little more brittle, but is less invasive to the actual code you are testing. For a great explanation on why this works, see this blog post.

// Configure the default task scheduler to use the current synchronization context.
Type taskSchedulerType = typeof(TaskScheduler);
FieldInfo defaultTaskSchedulerField = taskSchedulerType.GetField("s_defaultTaskScheduler", BindingFlags.SetField | BindingFlags.Static | BindingFlags.NonPublic);
defaultTaskSchedulerField.SetValue(null, TaskScheduler.FromCurrentSynchronizationContext());

Unfortunately, this will not work as expected from a unit test assembly. This is because unit tests, like Console applications, do not have a SynchronizationContext and you will get the following error message.

Error: System.InvalidOperationException: The current SynchronizationContext may not be used as a TaskScheduler.

To fix this you just need to set the SynchronizationContext in your test setup.

// Configure the current synchronization context to process work synchronously.
SynchronizationContext.SetSynchronizationContext(new SynchronizationContext());

This will get rid of the error, but some of your tests may still fail. This is because the default SynchronizationContext posts work asynchronously to the ThreadPool. To override this, simply subclass the default SynchronizationContext and override the Post method as follows.

public class TestSynchronizationContext : SynchronizationContext
{
    public override void Post(SendOrPostCallback d, object state)
    {
        Send(d, state);
    }
}

With this in place, your test setup should look like the code below and all of the Tasks in your code under test will run synchronously by default.

// Configure the current synchronization context to process work synchronously.
SynchronizationContext.SetSynchronizationContext(new TestSynchronizationContext());

// Configure the default task scheduler to use the current synchronization context.
Type taskSchedulerType = typeof(TaskScheduler);
FieldInfo defaultTaskSchedulerField = taskSchedulerType.GetField("s_defaultTaskScheduler", BindingFlags.SetField | BindingFlags.Static | BindingFlags.NonPublic);
defaultTaskSchedulerField.SetValue(null, TaskScheduler.FromCurrentSynchronizationContext());

Note that this does not prevent a Task from being started with a custom scheduler. In such a case, you would need to pass that custom scheduler in using Dependency Injection and then pass in a synchronous scheduler during tests.

Answer 2

Good Question. I will be trying your option 3 with some slight changes.

1. Make InteractionRequest testable, such that the test method can choose whether to confirm or cancel the operation. So this allows testing the individual paths. You can use IoC technique (inversion of control )
2. Refactor all logic in DoWork & RunWorkerCompleted to separate methods, this allows to test these methods independently (if required).
3. Then add a new flag IsAsyncFlag to indicate if this needs to be executed asynchronously or not. Turn off the Async mode when running the tests.

There is a lot of emphasize on the test coverage. But in my experience 100% test coverage is very difficult to achieve and it can never be a synonym to code quality. Hence my focus is in identifying & writing tests that would add value to the solution.

If you have found a better approach, please share.