title: How to Unit Test BackgroundWorker + PRISM InteractionRequest?
body: <p>I have a reoccurring pattern in my WPF MVVM applications that has the following structure.</p>
  
  <pre class="lang-cs prettyprint-override"><code>public class MyViewModel : NotificationObject
  {
      private readonly IService _DoSomethingService;
  
      private bool _IsBusy;
      public bool IsBusy
      {
          get { return _IsBusy; }
          set
          {
              if (_IsBusy != value)
              (
                  _IsBusy = value;
                  RaisePropertyChanged(() =&gt; IsBusy);
              )
          }
      }
  
      public ICommand DisplayInputDialogCommand { get; private set; }
      public InteractionRequest&lt;Notification&gt; Error_InteractionRequest { get; private set; }
      public InteractionRequest&lt;Confirmation&gt; GetInput_InteractionRequest { get; private set; }
  
      // ctor
      public MyViewModel(IService service)
      {
          _DoSomethingService = service;
  
          DisplayInputDialogCommand  = new DelegateCommand(DisplayInputDialog);
          Error_InteractionRequest = new InteractionRequest&lt;Notification&gt;();
          Input_InteractionRequest = new InteractionRequest&lt;Confirmation&gt;();
      }
  
      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
                  }
              );
          }
      }
  }
  </code></pre>
  
  <p>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.</p>
  
  <p>In the provided code example, initiating this workflow will perform the following operations.</p>
  
  <ol>
  <li><p>Raise the <code>Input_InteractionRequest</code> <code>Raised</code> event to display a dialog in the UI for the purpose of collecting user input.</p></li>
  <li><p>Invoke the <code>ProcessInput</code> callback (triggered when the user completes the dialog).</p></li>
  <li><p>Check the <code>Confirmed</code> property of the <code>InteractionRequest</code> context to determine if the dialog was confirmed or canceled.</p></li>
  <li><p>If confirmed...</p>
  
  <ol>
  <li><p>Set the IsBusy flag.</p></li>
  <li><p>Start a <code>BackgroundWorker</code> to perform the long running <code>_DoSomethingService.DoSomething()</code> operation.</p></li>
  <li><p>Unset the IsBusy flag.</p></li>
  <li><p>If an error occurred in DoSomething_DoWork, raise the <code>Error_InteractionRequest</code> <code>Raised</code> event to display a message box in the UI for the purpose of informing the user that the operation was not successful.</p></li>
  </ol></li>
  </ol>
  
  <p>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.</p>
  
  <ol>
  <li><p>Replace <code>BackgroundWorker</code> with <code>IBackgroundWorker</code> and inject it via ctor. Use a synchronous <code>IBackgroundWorker</code> 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 <code>InteractionRequest</code> callback either.</p></li>
  <li><p>Use <code>System.Threading.Thread.Sleep(int)</code> to allow the <code>BackgroundWorker</code> 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 <code>InteractionRequest</code> callback.</p></li>
  <li><p>Refactor the <code>BackgroundWorker</code> methods and <code>InteractionRequest</code> callback into <a href="http://xunitpatterns.com/Humble%20Object.html" rel="nofollow">Humble Objects</a> that can be syncronously and independently tested. This seems promising, but structuring it has me stumped.</p></li>
  <li><p>Unit test <code>DoSomethingWorker_DoWork</code>, <code>DoSomethingWorker_RunWorkerCompleted</code>, and <code>ProcessInput</code> 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.</p></li>
  </ol>
  
  <p>What is the best way to unit test and/or refactor the above pattern to provide maximum code coverage?</p>