Vidar’s Musings

No measurement beats WTFs/min!

When trying to introduce unit tests into an existing project, code dependencies is often a problem. During a teeth-grinding session grappling with this problem I came to think about pure functions.

Pure functions are functions that (according to Wikipedia’s definition):

• always evaluates the same result value given the same argument value(s). The function result value cannot depend on any hidden information or state that may change as program execution proceeds, nor can it depend on any external input from I/O devices, and
• evaluation of the result does not cause any semantically observable side effect or output, such as mutation of mutable objects or output to I/O devices.

Seems to me that pure functions would be a wet dream for unit testing. Imagine, you could pass in whatever the function needed to execute, and then check its return value. No mocking about with mock objects with side effect expectations needed!

But alas, we live in a world with non-pure functions. Even in functional programming, which does explicitly keep any state, you find them. In an object oriented language a primary idea is that objects should carry state. An object has a state. Period. However, if we can be inspired by the notion of pure functions, and make methods that have less dependencies, we will be much better off when it comes to unit testing.

I my experience, the ASP.NET programming model with ASPX code behind files is a model that promotes writing methods that are problematic to create unit tests for.

Take, for example, the following (theoretical, I admit) code behind snippet example:

protected void Page_Load(object sender, EventArgs e)

    {

        ShowOrHideEditButton(Page.User.Identity.Name);

    }

    void ShowOrHideEditButton(string currentUser)

    {

        if (Request.QueryString["user"].Equals(currentUser))

        {

            EditButton.Enabled = true;

        }

        else

        {

            EditButton.Enabled = false;

        }

    }

So, what is the problem here? Actually, there are two problems.

1. The ShowOrHideMethod is not only dependant on its input parameters, but also on another member variable. When looking at the method signature, you do not see this, and might be misleaded about what the outcome of the methods is dependent on.
2. The method does not return any value, but has a side-effect on its environment (setting the edit button visibility).

These two issues, makes it troublesome to test the method in a unit test. You have spend time to set up the methods context, and you have to measure the method’s side effects in order to make assesments about its result.

A much better approach would be something like this:

    protected void Page_Load(object sender, EventArgs e)

    {

        EditButton.Enabled = ShowOrHideEditButton(Page.User.Identity.Name, Request.QueryString["user"]);

    }

    bool ShowOrHideEditButton(string currentUserName, string profilePerson)

    {

        return (currentUserName.Equals(profilePerson));

    }

This way, we can easily test the ShowOrHideEditButton method in a unit test without having to use a great deal test code to set up the test context.

For increased testability, I would suggest the following for better method purity:

• A method should evaluate the same result, given the same argument value(s) and object state.
• A method execution result should be represented as, in order of preference: 1) a return value, 2) changed object state (mutation), or 3) a side-effect on an I/O device

Encapsulation is one of the most important features of object orientation, but often easy to break in practice. One common mistake to make in this respect happens when creating a class that holds some sort of collection or array.

For example, let’s assume that we want to make an immutable object (meaning that its state should never change troughout its lifecycle):


public class Request
{
    private readonly string[] _acceptedTypes;
    public Request(params string [] acceptedTypes) {…}
    public string[] AcceptedTypes { get {…} }
    public bool Accepts(string type) {…}
}


We have a class that take a list of strings as parameter to the constructor. The intent is that the list of strings should never change. Typical use of the class would be something like this:


Request request = new Request("application/json", "application/x-json");
if (request.Accepts(somestring))
{
     ...
}


Here’s a naîve implementation of the class:


public class Request
{
    private readonly string[] _acceptedTypes;

    public Request(params string[] acceptedTypes)
    {
        _acceptedTypes = acceptedTypes;
    }

    public string[] AcceptedTypes { get { return _acceptedTypes; } }

    public bool Accepts(string type)
    {
        foreach (string acceptableType in _acceptedTypes)
        {
            if (acceptableType.Equals(type))
            {
                return true;
            }
        }
        return false;
    }
}


Our intent of creating an immutable object is here manifested in the ‘readonly’ keyword used when defining the member variable _acceptedTypes, and the fact that there is only a set accessor for the AcceptedTypes property. But alas, there are several issues that break our intent.

First, let’s have a look at the AcceptedTypes accessor. It allows us to write code such as this:


request = new Request("application/json", "application/x-json" );

bool accepts1 = request2.Accepts("application/javascript");
request.AcceptedTypes[1] = “application/javascript”;
bool accepts2 = request.Accepts(”application/javascript”);


After running this code, we find that accepts1 != accepts2. We have been able to manipulate the state of the object (in other words, it is mutable). The problem is that the AcceptedTypes exposes a reference to the array of types. Alternatively, it could only expose an IEnumerable that can be used to iterate over the types:


public IEnumerable AcceptedTypes
{
get
{
    foreach (string acceptableType in _acceptedTypes)
{
yield return acceptableType;
}
    }
}


Then, it will not be possible to manipulate the state of the object by calling request.AcceptedTypes[i].
Still, there is one problem with the current implementation. We still can write code such as this:


string[] types = new string[] { “application/json”, “application/x-json” };
Request request = new Request(types);
bool accepts1 = request.Accepts(”application/javascript”);
types[1] = “application/javascript”;
bool accepts2 = request.Accepts(”application/javascript”);


After running this code, accepts1 != accepts2. The problem is that we pass a referene to the constructor, and the object instance stores it in its local variable. We are free to change the object that our reference points to, indirectly changing the state of the object. In order to fix this, we change the constructor code for Request:


public Request(params string[] acceptedTypes)
{
_acceptedTypes = new string[acceptedTypes.Length];
Array.Copy(acceptedTypes, _acceptedTypes, acceptedTypes.Length);
}