Dealing with DependencyObjects in Silverlight Unit Tests

Question

I have been writing unit tests using NUnit and Moq with my Silverlight code for some time now. One problem I keep running into has to do with DependencyObjects.

If anything is derived from DependencyObject, then I can't instantiate it in my test. For instance, MouseEventArgs derives from DependencyObject. If I have code that takes these args, I can't create the args for several reasons... one of them being that it is a DependencyObject.

As far as I understand, the base constructor of DependencyObject is trying to work with some statics that don't exist unless the entire Silverlight system is up and running. Any construction of a class that derives from DependencyObject throws an exception. Bummer.

I do not use the Silverlight Unit Test Framework, because it really isn't unit testing and requires a UI. I run need real, headless unit tests.

Anyways, The best I have come up with is to wrap these objects and give them interfaces like ITimelineMarker and I give them extension methods to do it: timelineMarker.ToInterface(). This works well, and I can mock them out... but I was wondering:

Has anyone come up with a better way to deal with DepencencyObjects in Silverlight Unit Tests?

Answer 1

Have you had a look at TestDriven.NETs Silverlight NUnit Project? Link

Answer 2

I can see that DependencyObject in an abstract class.

Shamelessly ripping from Rhino mocks documentation, imagine you have an abstract class:

public abstract class MessageBase {
   private List<User> _receivers = new List<User>();
   public void Send() {
      //Some setup
      DetermineReceivers();
      SendMessages();
   }
   private void SendMessages() {
      //Lots of logic
   }
   protected abstract void DetermineReceivers();
   protected void AddReceiver(Group g) {
      //Lots of logic <---- Test this
   }
}

and you want to test the indicated part. Then you would create a fake class that you can mock:

TestFixture
public sealed class MessageBaseTester {
 public abstract class MockMessageMocker
 {
    public abstract List<Group> RecipientsGroups { get; set; }
 }
 private class MockMessage : MessageBase {
   private MockMessageMocker _mock;
   public MockMessage(MockMessageMocker mock) {
      _mock = mock;
   }
   protected override void DetermineReceivers() {
      if (_mock.RecipientsGroups != null)
         foreach(Group g in _mock.RecipientsGroups)
            base.AddReceiver(g);
   }
 }
}

Afterwards your test can do the following:

 Test
 public void ShouldblablablaWhenBlabla() {
    var SuThelper = mocks.Stub();
    var SuT = new MockMessage(SuThelper);
    using (mocks.Record())
    {
       Expect.Call(SuTHelper.RecipientsGroups).Return(
             new List<Group>{ new Group(...) });
    }
    using (mocks.Playback())
    {
       SuT.Send();
    }
 }

The above solution has an advantage over yours, in that you do not need to modify your original code. However you need to write some "extra" code for it to work.

Answer 3

Try using SilverUnit for unit testing Silverlight. Since it's faking the Silverlight infrastructure, it may help with the problematic exceptions.

Answer 4

Why do you have application logic tied directly to SilverLight events and objects? The caveats of trying to test an application's logic through it's UI are well known anti-patterns and have given way to patterns that solve this problem in a more effective manner.

Your UI really should only be concerned with UI events and pass any processing to another layer, the only thing then left to test in your UI would be graphical responses (such as when you click a button does a panel slide in from the side), and the only good way to test interactions like that is to actually do the clicking.

Perhaps a more appropriate answer to your question would be that you need to refactor your code to use a patter such as MVC, MVP, or MVVM so that you can test your application logic independently of your UI layer.