Dealing with Dependencies in Test-Driven Development through Mocking

Mocking is generally an overloaded term. But at its base, it's about changing behavior -- specifically, dependency behavior.

I'm a big fan of Test Driven Development (TDD); but I've discovered that some things are easy to unit test (e.g. interfaces, objects) and some things are hard. Dependencies between classes create problems -- if the class I'm testing class creates and uses some object, the validity of my test is compromised. If my test fails, have I proven that the class I'm testing has a problem? Or have I proved that the object the class calls has a problem?

I asked Gil Zilberfeld, a Product Manager for TypeMock, for some advice. Gil has more than 15 years of experience in software development, from coding to team management and process implementation. Here's what he said about solving my problems with Mocking.

Mocking is generally an overloaded term. But at its base, it's about changing behavior -- specifically, dependency behavior. Working with MSMQ was my first mock object.

I needed to write to a queue. This was the first version of the method I wanted to test:

 public class RealMessageQueue : IMessageQueue
  {
    var queue = MessageQueue.Create("AnyQueue");

    public void Send(object message)
    {
        queue.Send(message);
    }
  }

My test for that method looked like this:

[TestMethod]
  public void Send_StringMessage_MessageWasSent()
  {
    var messageQueue = new MessageQueue();
    Server.SendMessage(messageQueue, "message");
  }

This isn't a great test; it only fails if the method blows up. So I added some code to read the message back from the queue to make sure that the message had arrived. But queues (which is the dependency of Server, in this case) sometimes behave funny. And we don't like funny, we like dependable. In this case, the message did arrive -- sort of. Because MSMQ has an (asynchronous) mind of its own, sometimes the message arrived before the test ended (success) and sometimes after (failure).

I couldn't control the queue's behavior, so I had to replace it with another object—a mock object—that I could control. So I changed the signature of my SendMessage method a bit:

public class Server
  {
    public void SendMessage(IMessageQueue queue, object message)
    {
      queue.Send(message);
    }
  }

Now I'm not passing a MessageQueue object to my SendMessage method. Instead, I'm sending an object that implements the IMessageQueue interface. My interface looks like this:

public interface IMessageQueue
  {
    void Send(object message);
  }

Now I can inject any object implementing the IMessageQueue interface into my test. For example, my real MessageQueue object already implemented the IMessageQueue interface looked like this:

 public class RealMessageQueue : IMessageQueue
  {
    var queue = MessageQueue.Create("AnyQueue");

    public void Send(object message)
    {
        queue.Send(message);
    }
  }

But another, a fake MessageQueue object could implement the interface also. I could add a property to my fake that supported testing:

public class FakeMessageQueue : IMessageQueue
  {
    public bool messageWasSent = false;
    public void Send(object message)
    {
      messageWasSent = true;
    }
  }

Now, with my FakeMessageQueue, I can actually create tests that return a value when the message is sent:

[TestMethod]
  public void Send_StringMessage_MessageWasSent()
  {
    var fakeMessageQueue = new FakeMessageQueue();

    var server = new Server();
    server.SendMessage(fakeMessageQueue, "message");

    Assert.IsTrue(fakeMessageQueue.messageWasSent);
  }

And that's the whole idea behind mocking -- the ability to change behavior of the objects you're working with to improve the quality of your tests.

But creating mock objects by coding every one of them by hand is a very tiring way to go. Today, there are tools to do the same thing, with much less hassle: isolation frameworks. This is one of the great benefits of tools like Typemock Isolator .NET -- the ability to fake any dependency, even privately declared variables and static/Shared methods or properties. If you want to use TDD, you're also going to need an isolation framework. There are several out there but, of course, I think TypeMock Isolator .NET is the best.

If you want more from Gil, he presents, blogs, and talks constantly about unit testing to encourage developers (from beginning to experienced) to implement unit testing as a core practice in their projects.

About the Author

Peter Vogel is a system architect and principal in PH&V Information Services. PH&V provides full-stack consulting from UX design through object modeling to database design. Peter tweets about his VSM columns with the hashtag #vogelarticles. His blog posts on user experience design can be found at http://blog.learningtree.com/tag/ui/.

comments powered by Disqus

Featured

  • Xamarin.Forms 5 Preview Ships Ahead of .NET 6 Transition to MAUI

    Microsoft shipped a pre-release version of Xamarin.Forms 5 ahead of a planned transition to MAUI, which will take over beginning with the release of .NET 6 in November 2021.

  • ML.NET Improves Object Detection

    Microsoft improved the object detection capabilities of its ML.NET machine learning framework for .NET developers, adding the ability to train custom models with Model Builder in Visual Studio.

  • More Improvements for VS Code's New Python Language Server

    Microsoft announced more improvements for the new Python language server for Visual Studio Code, Pylance, specializing in rich type information.

  • Death of the Dev Machine?

    Here's a takeaway from this week's Ignite 2020 event: An advanced Azure cloud portends the death of the traditional, high-powered dev machine packed with computing, memory and storage components.

  • COVID-19 Is Ignite 2020's Elephant in the Room: 'Frankly, It Sucks'

    As in all things of our new reality, there was no escaping the drastic changes in routine caused by the COVID-19 pandemic during Microsoft's big Ignite 2020 developer/IT pro conference, this week shifted to an online-only event after drawing tens of thousands of in-person attendees in years past.

Upcoming Events