Mocks and fakes and stubs, oh my!

Yesterday, I started writing an article about mocks and fakes and stubs, but ended up writing an article about Inversion of Control (IoC) / Dependency Injection. Today, I’ll take up the topic of how to isolate your code from that of other objects in your unit tests. But, first, what are mocks, fakes and stubs?

In his article Mocks Aren’t Stubs, Martin Fowler defines mocks, fakes, stubs and dummy objects as follows:

  • Dummy objects are passed around but never actually used. Usually they are just used to fill parameter lists.
  • Fake objects actually have working implementations, but usually take some shortcut which makes them not suitable for production (an in memory database is a good example).
  • Stubs provide canned answers to calls made during the test, usually not responding at all to anything outside what's programmed in for the test. Stubs may also record information about calls, such as an email gateway stub that remembers the messages it 'sent', or maybe only how many messages it 'sent'.
  • Mocks are objects pre-programmed with expectations which form a specification of the calls they are expected to receive.

All of these objects are useful when unit testing your code. But, each type of test object has it’s own strengths and weaknesses. Let’s look at how to use each type of test object (except for dummy objects) to isolate the Add method from the Logger object that it uses.

Here, again, is the code for the IocCalculator class (modified slightly, to actually throw overflow exceptions):

public class IocCalculator
{
    public IocCalculator(ILogger logger)
    {
        Logger = logger;
    }

    private ILogger Logger { get; set; }

    public int Add(params int[] args)
    {
        Logger.Log("Add");

        int sum = 0;
        try
        {
            foreach (int arg in args)
                sum = checked(sum + arg);
        }
        catch (OverflowException ex)
        {
            Logger.Log("OverflowException: Add");
            throw ex;
        }

        return sum;
    }
}

Dummy Objects

First, let’s try testing this code with a dummy object:

public class DummyLogger : ILogger
{
    public void Log(string message)
    {
    }
}
[Test]
[ExpectedException(typeof(OverflowException))]
public void AddThrowsExceptionOnOverflow()
{
    var calculator = new IocCalculator(new StubLogger());
    calculator.Add(int.MaxValue, 1);
}

Take a look at the dummy object, above. It doesn’t do anything. It just swallows the calls to the logger from the Add method. Is this useful? Actually, yes. It allowed us to test that the exception was thrown correctly. Is it a good fit for this test? Yes. Can it do everything a mock, fake or stub can do? No.

Mock Objects

For example: What if we actually wanted to ensure that the Add method actually called the logger? In that case, a mock object might be more useful:

[Test]
public void AddLogsExceptionOnOverflow()
{
    var mocks = new Mockery();
    var mockLogger = mocks.NewMock<ILogger>();
    Expect.Exactly(2).On(mockLogger).Method("Log");

    var calculator = new IocCalculator(mockLogger);

    Assert.Throws(typeof(OverflowException), () => calculator.Add(int.MaxValue, 1));
    mocks.VerifyAllExpectationsHaveBeenMet();
}

This test replaces the dummy logger object with a mock logger object that the test itself creates (using the NMock framework). The first three lines setup the mock object by instantiating the mock object framework, instantiating the mock logger object from the ILogger interface, and telling NMock to expect two calls to the “Log” method on the mock logger object. Behind the scenes, mockLogger.Log counts the number of times it gets called. The final line of the test then compares the number of times we expected to call mockLogger.Log with the actual number of times it was called.

(Note: The Assert statement above uses a lambda expression to invoke an anonymous method, which in and of itself is a delegate. This syntax was introduced in C# 3.0. If you find it a bit obtuse, you’re not alone. Perhaps it’d make a good blog post. Anyone want to write it?)

One final note on mocks: Many in the Test Driven Development community are enamored with mock objects. Some developers use mocks to the exclusivity of all other types of test objects. Personally, I prefer to do state-based testing rather than behavior based testing. In other words, I want to setup my object under test, call the method under test, and assert that the state of the object changed in some observable way. I don’t want my test to know about the underlying implementation details of the method under test. Mock objects, in my opinion, have a way of getting cozy with implementation details that makes me uncomfortable.

Fake Objects

But, what if you want to test that the Add method logs the correct messages? In that case, you may need to implement a fake logger and validate it’s contents, like this:

public class FakeLogger : ILogger
{
    public readonly StringBuilder Contents = new StringBuilder();

    public void Log(string message)
    {
        Contents.AppendLine(message);
    }
}
[Test]
public void AddLogsCorrectExceptionOnOverflow()
{
    var fakeLogger = new FakeLogger();
    var calculator = new IocCalculator(fakeLogger);

    Assert.Throws(typeof(OverflowException), () => calculator.Add(int.MaxValue, 1));
    Assert.AreEqual("Add\nOverflowException: Add\n", fakeLogger.Contents.ToString());
}

Note that the fake logger is actually a real logger. It actually logs the messages it receives in a string (using a StringBuilder object). Essentially, this implementation is an “in memory” logger, similar to what Fowler described as an “in memory database.” In fact, if this weren’t an example, I would probably have named the class InMemoryLogger or StringLogger, rather than FakeLogger. That’s more in line with what the code actually does.

So, is the fake logger useful? Absolutely. In fact, this is the approach I would actually take, since the dummy and mock loggers cannot check the text that was logged.

Stub Objects

But, what about stub objects? Well, it turns out that I chose a poor example for illustrating stub objects. As you’ll recall from above, stubs return hard-coded values to trigger specific code paths within the code under test. My logger example doesn’t need this kind of functionality. But, if a method were to call the Add method, it might be handy to use a stub to hard code a response, like this:

So, let’s test some code that needs to call the Calculator object. First, here’s the code:

public class Decider
{
    public bool Decide(params int[] args)
    {
        return ((new IocCalculator(new DummyLogger()).Add(args) % 2) == 1);
    }
}

Hmmm… Well, we can’t isolate this code from the IocCalculator code, yet. Let’s refactor:

public class Decider
{
    private readonly ICalculator _calculator;

    public Decider(ICalculator calculator)
    {
        _calculator = calculator;
    }

    public bool Decide(params int[] args)
    {
        return ((_calculator.Add(args) % 2) == 1);
    }
}

Now, we can pass in a couple off different stub objects to test the Decider.Decide method:

public class EvenCalculator : ICalculator
{
    public int Add(params int[] args)
    {
        return 2;
    }
}

public class OddCalculator : ICalculator
{
    public int Add(params int[] args)
    {
        return 1;
    }
}

[TestFixture]
public class DeciderFixture
{
    [Test]
    public void DecideReturnsFalseWhenEven()
    {
        var decider = new Decider(new EvenCalculator());
        Assert.False(decider.Decide());
    }

    [Test]
    public void DecideReturnsTrueWhenOdd()
    {
        var decider = new Decider(new OddCalculator());
        Assert.True(decider.Decide());
    }
}

Conclusion

So, that (finally) concludes my look at mocks, fakes, stubs and dummies. I hope you found it understandable. And, I hope you find it helpful the next time you need to test a piece of code in isolation. In fact, this same Inversion of Control / Dependency Injection approach can be leveraged in many different ways. My focus in these articles was to demonstrate using the approach in unit testing. But, it can also be applied to functional/system testing.

Say you have a website that displays data returned from a web service. Say you want to hide the Address2 line if it is empty. You could look for test data from the web service that meets your needs. Or, you could program your tests to run against a stub service that returns just the values you need. Not only will you be guaranteed that the test data won’t change, but the test will run much faster, to boot. Sure, an end-to-end that calls the actual web service test will be necessary before going live. But, why pay that price every time you run your test suite.

Furthermore, IoC can also be used in production code to enable things like plug-ins or composite user interfaces. In this scenario, an installed plug-in is generally just a piece of code that implements a specific interface – one that allows a third party to develop software that integrates with your code at runtime via configuration.

As always, feel free to post corrections and questions in the comments.

Inversion of Control (IoC) / Dependency Injection

When I first started building unit tests for my code, I would create a little user interface through which I could plug in various inputs and see the output. It was a highly manual process. But, it was also NOT unit testing. Rather, I was integration testing my objects and any objects referenced by my objects. Even when I began using tools like NUnit to do unit testing, I continued writing integration tests and calling them unit tests. It wasn’t until I learned about the “inversion of control” (or, IoC) design pattern that I began writing truly discreet tests.

Smarter people than I have written a bunch about IoC. So, rather than try to explain it, let’s look at an example. The following code uses a logger to write messages to an event log:

public class Calculator
{
    public int Add(params int[] args)
    {
        var logger = new EventViewerLogger("Application");
        logger.Log("Add");

        int sum = 0;
        try
        {
            foreach (int arg in args)
                sum += arg;
        }
        catch (OverflowException ex)
        {
            logger.Log("OverflowException: Add");
            throw ex;
        }

        return sum;
    }
}

Notice that the method directly instantiates the logger. Imagine trying to test this method without also testing the logger. It is simply not possible. Furthermore, this code violates both the Single Responsibility Principle and the Open/Closed Principle.

The Single Responsibility Principle states that a class/method must have only one responsibility. In this case, the appropriate responsibility is mathematical calculations. Instantiating objects counts as a second responsibility. Thus, the violation.

The Open/Closed Principle states that a class/method should be open for extension, but closed for modification. The way I’m using this term, the violation is in the fact that the Add method creates an instance of a concrete class, rather than referencing an interface. In doing so, it is impossible to change the logging behavior of this class/method without modifying the class itself.

Here’s how that same code would look after addressing these issues:

public class IocCalculator
{
    public IocCalculator(ILogger logger)
    {
        Logger = logger;
    }

    private ILogger Logger { get; set; }

    public int Add(params int[] args)
    {
        Logger.Log("Add");

        int sum = 0;
        try
        {
            foreach (int arg in args)
                sum += arg;

        }
        catch (OverflowException ex)
        {
            Logger.Log("OverflowException: Add");
            throw ex;
        }

        return sum;
    }
}

Now, the logger is instantiated outside the method. In fact, it is instantiated outside the class entirely and passed in via a constructor. (This is called Constructor Dependency Injection, which is a form of IoC.)

Furthermore, the class now references the ILogger interface rather than the EventViewerLogger concrete class. This allows for the client object to determine which logger should be used. In a production environment, that might be the EventViewerLogger, or it might be a DatabaseLogger. More interesting to this discussion, however, is the fact that now we can use a MockLogger, FakeLogger or StubLogger to test the calculation code without also testing the logger code.

So, what are mocks, fakes and stubs? They’re the subject of a future post. Stay tuned.

Moving past and to the semantic web

In his recent conversation, a coworker mentioned if you’re still using the <table> tag to layout your web pages, “you need to move out of the 90’s.” Of course, I agree. And, I frequently use <div> tags instead of <table> tags.

But, a little digging on the web has shown me I’ve probably been overusing <div> tags. Instead, the recommendations I’m seeing (links at the bottom of this post) are to limit <div> tags to the main layout of your page – things like headers, content, side-bars, and footers. Then, use traditional HTML markup for the content inside each area of your layout.

One such example I ran across used the <fieldset> and <ol> tags to render a form. It looked like this:

<form>
  <fieldset>
    <legend>Please enter your credentials:</legend>
    <ol>
      <li>
        <label for="username">User Name:</label>
        <span class="input"><input type="text" id="username"/></span>
      </li>
      <li>
        <label for="password">Password:</label>
        <span class="input"><input type="text" id="password"/></span>
      </li>
      <li>
        <span class="submit"><input type="button" id="login" value="Login"/></span>
      </li>
    </ol>
  </fieldset>
</form>

Without any CSS, it rendered like this:

image

Of course, that’s not the nicest looking form. But, it does provide some distinct advantages – especially to users who depend on accessibility tools to “view” the web. By enclosing the elements of the form in an ordered list (<ol>), for example, the user can hear how many elements there are in the form.

And, by enclosing all of the fields in a <fieldset>, we give the user additional context that gets repeated with each <label> in the form. This would be particularly useful for a shopping cart, where the Address fields might be repeated in multiple contexts, such as shipping address and billing address. Just enclose each group of fields in a separate <fieldset> and give them an appropriate <legend>.

To get the form to look less like a list and more like a traditionally (<table>) formatted form, I used this CSS:

<style type="text/css">
    fieldset {
        width: 260px;
        border: solid 1px black;
        }
    ol {
        list-style: none;
        margin: 0px 0px 0px -60px ;
        }
    li {
        display: table-row;
        }
    li label {
        width: 100px;
        float: left;
        text-align: right;
        padding: 5px;
        }
    li .input {
        width: 140px;
        float: right;
        text-align: left;
        padding: 5px;
        }
</style>

After which, it rendered like this:

image

Or, after another five minutes, I created this CSS, to render the <label> tags above the <input> tags:

<style type="text/css">
    fieldset {
        width: 200px;
        border: solid 1px black;
        }
    ol {
        list-style: none;
        margin: 0px 0px 0px -30px ;
        }
    li {
        display: table-row;
        }
    li label {
        width: 100px;
        padding: 5px;
        }
    li .input {
        width: 140px;
        float: left;
        text-align: left;
        padding: 5px;
        }
</style>

This rendered the form like this:

image

So, in the end, I learned something today. I hope you do to!

Here are the links I promised:

Enjoy!

On Clarity and Abstraction in Functional Tests

Consider the following tests:

[Test]
public void LoginFailsForUnknownUser1()
{
    string username = "unknown";
    string password = "password";

    bool loginSucceeded = User.Login(username, password);

    Assert.That(loginSucceeded == false);
}
[Test]
public void LoginFailsWithUnknownUser2()
{
    using (var browser = new IE(url))
    {
        browser.TextField(Find.ById(new Regex("UserName"))).Value = "unknown";
        browser.TextField(Find.ById(new Regex("Password"))).Value = "password";

        browser.Button(Find.ById(new Regex("LoginButton"))).Click();
        bool loginSucceeded = browser.Url.Split('?')[0].EndsWith("index.aspx");

        Assert.That(loginSucceeded == false);
    }
}

Note the similarities:

  • Both methods test the same underlying functional code; and,
  • Both tests are written in NUnit.
  • Both tests use the Arrange / Act / Assert structure.

Note the differences:

  • The first is a unit test for a method on a class.
  • The second is a functional test that tests an interaction with a web page.
  • The first is clear. The second is, um, not.

Abstracting away the browser interaction

So, what’s the problem? Aren’t all browser tests going to have to use code to automate the browser?

Well, yes. But, why must that code be so in our face? How might we express the true intention of the test without clouding it in all the arcane incantations required to automate the browser?

WatiN Page Classes

The folks behind WatiN answered that question with something called a Page class. Basically, you hide all the browser.TextField(…) goo inside a class that represents a single page on the web site. Rewriting the second test using the Page class concept results in this code:

[Test]
public void LoginFailsWithUnknownUser3()
{
    using (var browser = new IE(url))
    {
        browser.Page<LoginPage>().UserName.Value = "unknown";
        browser.Page<LoginPage>().Password.Value = "password";

        browser.Page<LoginPage>().LoginButton.Click();
        bool loginSucceeded = browser.Page<IndexPage>().IsCurrentPage;

        Assert.That(loginSucceeded == false);
    }
}
public class LoginPage : Page
{
    public TextField UserName
    {
        get { return Document.TextField(Find.ById(new Regex("UserName"))); }
    }
    public TextField Password
    {
        get { return Document.TextField(Find.ById(new Regex("Password"))); }
    }
    public Button LoginButton
    {
        get { return Document.Button(Find.ById(new Regex("LoginButton"))); }
    }
}

Better? Yes. Now, most of the WatiN magic is tucked away in the LoginPage class. And, you can begin to make out the intention of the test. It’s there at the right hand side of the statements.

But, to me, the Page Class approach falls short. This test still reads more like its primary goal is to automate the browser, not to automate the underlying system. Plus, the reader of this test needs to understand generics in order to fully grasp what the test is doing.

Static Page Classes

An alternative approach I’ve used in the past is to create my own static classes to represent the pages in my web site. It looks like this:

[Test]
public void LoginFailsWithUnknownUser4()
{
    using (var browser = new IE(url))
    {
        LoginPage.UserName(browser).Value = "unknown";
        LoginPage.Password(browser).Value = "password";

        LoginPage.LoginButton(browser).Click();
        bool loginSucceeded = IndexPage.IsCurrentPage(browser);

        Assert.That(loginSucceeded == false);
    }
}
public static class LoginPage
{
    public static TextField UserName(Browser browser)
    {
        return browser.TextField(Find.ById(new Regex("UserName")));
    }
    public static TextField Password(Browser browser)
    {
        return browser.TextField(Find.ById(new Regex("Password")));
    }
    public static Button LoginButton(Browser browser)
    {
        return browser.Button(Find.ById(new Regex("LoginButton")));
    }
}

This is the closest I have come to revealing the intention behind the functional test without clouding it in all the arcane incantations necessary to animate a web browser. Yes, there are still references to the browser. But, at least now the intention behind the test can be inferred by reading each line from left to right. Furthermore, most of the references to the browser are now parenthetical, which our eyes are accustomed to skipping.

What do you think?

I’d like to know what you think. Are your functional tests as clear as they could be? If so, how’d you do it? If not, do you think this approach might be helpful? Drop me a line!

On Logical Layers and Physical Tiers

This post came out of a team design discussion last summer. We were trying to decide how to layer and deploy a new tool for administering part of our system. In order to work through the options, I took a step back and thought about design in the abstract. It helped me a great deal at the time. I hope it helps you, too.

Logical Application Layers

It makes good sense to design applications in logical layers. In most modern business applications, there are (at least) three layers:

  1. A UI layer to display information to the user and handle user input;
  2. A “middle-tier” or business layer to handle data validation and process business rules; and,
  3. A data access layer to handle storage and retrieval of data from some form of repository.

This allows you to keep all of your UI code together in one place, separate from the business rules and data access code (increasing cohesion). And, it makes it easy for you to ensure that the UI code never calls the data access code directly (reducing coupling). These are the hallmarks of good OO design.

Physical Application Tiers

It may also make sense to deploy your logical layers across multiple physical environments (or tiers). For example, you could:

  1. Deploy all three layers to a single physical environment (though not generally recommended), or
  2. Deploy the UI layer to a separate environment in a DMZ, or
  3. Deploy all three layers to separate physical tiers.

This allows you to improve security (through the use of firewalls and service accounts). And, it allows you to improve performance (through the use of load balancers at each tier). These are the hallmarks of a well deployed application. Notice though, that to do this, you need to design logical layers into your application well before you try to deploy it.

Packaging Logical Layers for Deployment to Physical Tiers

Packaging is the process of placing classes into DLLs. In other words, how do I decide where to put a new class when creating it? Obviously, if I plan to deploy the application across multiple physical environments, then it makes sense to create multiple packages (or DLLs). But, if I decide to host two (or more) layers on the same physical tier, I may still want to package those layers separately, and deploy both DLLs. So, packaging decisions can be influenced by deployment decisions, but not the other way around.

Furthermore, how you package your logical layers (in one, two or three DLLs) and where you deploy your logical layers (on one, two or three physical environments) has nothing to do with the logical layers themselves. In other words, no matter how I package and deploy my application, it will still contain the same classes and methods in each logical layer.

Service Layers

If you choose to deploy your logical layers on a single physical environment, each layer can call its subordinate layers directly (regardless of how many DLLs you create). But, if you choose to deploy your logical layers across multiple physical environments, then you’re going to need some glue to allow the layers to communicate across those environments. A common approach to this issue is to introduce a thin service layer between two logical layers to handle the communications, like this:

  • Front-end Tier
    • UI Layer
    • Service Layer Proxy
  • Back-end Tier
    • Service Layer
    • Business Layer
    • Data Access Layer

Notice that the service layer in this case actually spans the two physical environments. A portion of the service layer, called the “proxy” lives on the front-end. And, the remainder of the service layer lives on the back-end. Microsoft does a good job of hiding all this from you in WCF. But, the underlying proxy and service layers are still there.

The important thing to remember about service layers is that they should only handle the communications across physical environments. There should be no UI, business or data access logic in the service layer or its proxy. Again, this goes to increasing cohesion and reducing coupling.

Applying the Single Responsibility Principle

I reviewed a bit of code today that presents an excellent opportunity to discuss a big difference between procedural and object-oriented code. Here’s the code I reviewed:
private void DisplayCoBrandedImages()
{
    string imageUrl = "~/images/cobrand/" + ContractId + ".gif"; 
    bool isCoBranded = File.Exists (Server.MapPath(imageUrl)); 
    bool isGroup = (Page.Category & DisplayCategory.GroupLevel) == 
        Page.Category;

    if (isGroup)
    { 
        imageUrl = "~/images/cobrand/GroupOnlineLogo.gif";
    }

    _brandedImage.Visible = isCoBranded || isGroup; 
    _brandedImage.ImageUrl = imageUrl;
}
This is a good example of procedural code, where a single method has multiple responsibilities. In this case, the method DisplayCoBrandedImages is:
  • Determining if the page should be co-branded;
  • Determining if the page is a group page;
  • Determining which image to display; and,
  • Setting the properties of the image control.
In object-oriented programming, however, we strive to follow the Single Responsibility Principle, which states that code should only have one reason to change. But, any of the tasks mentioned above might change independently of the other tasks. So, if I were to refactor this code into a more object-oriented structure, I would expect to see a different method (or property) handling each of those items above, like this:
private void DisplayCoBrandedImages()
{ 
    _brandedImage.Visisble = IsCoBranded || IsGroup; 
    _brandedImage.ImageUrl = GetImageUrl(); 
}

private bool IsCoBranded
{
    get { return File.Exists(ImageUrl); }
}

private bool IsGroup
{ 
    get { return (Page.Category & DisplayCategory.GroupLevel) == 
        Page.Category; }
}

private string ImageUrl
{
    get
    {
        if (IsGroup)
            return "~/images/cobrand/GroupOnlineLogo.gif";
        else
            return "~/images/cobrand/" + ContractId + ".gif";
    } 
}
Now, the primary method (DisplayCoBrandedImages) is only responsible for setting the attributes of the image control. It relies on helper methods (or, as in this case, properties) to perform the other, subordinate tasks. The resulting code, while longer, is easier to understand, because each method is only doing one thing.