jp.hamilton

Striving for Test Readability

jp — Thu, 21 May 2009 03:58:26 -0700

I have heard many times that tests are like documentation for other developers. The argument is that formal documentation (word documents, spreadsheets, etc.) rarely stays in sync with the current state of an application. Therefore, unit tests act as a kind of up to date documentation (provided that the tests are all passing, of course). Tests tell developers who are not familiar with the code, how an application should work and what the expectations are. But consider this test:

[TestFixture]
public class when_user_is_logging_in
{
    [Test]
    public void only_three_login_attempts_are_allowed()
    {
        ILoginView view = MockRepository.GenerateStub<ILoginView>();
        view.Stub(x => x.User).Return("bad");
        view.Stub(x => x.Password).Return("bad");

        ILoginService loginService = MockRepository.GenerateMock<ILoginService>();
        loginService.Expect(x => x.UserExists("bad", "bad")).Return(false);

        LoginPresenter presenter = new LoginPresenter(loginService);
        presenter.Initialize(view);

        view.Raise(x => x.TryLogin += null, this, EventArgs.Empty);
        view.Raise(x => x.TryLogin += null, this, EventArgs.Empty);
        view.Raise(x => x.TryLogin += null, this, EventArgs.Empty);

        view.AssertWasCalled(x => x.Close());
    }
}

Right away it’s pretty clear that “when a user is logging in, only three login attempts are allowed”. But things quickly go south after that. What mocking frameworks give us in convenience, they sure take away in readability. Regarding the above example - it’s written using Rhino Mocks 3.5. Many developers not familiar with mocking may be surprised to learn that this is actually the “good” syntax. Things used to be a heck of a lot worse. However, I still think that there are some things that could be done to clean these tests up, while still adhering to spirit of “tests that act like documentation”. My goal here, is to do this with as little ceremony as possible. I am not interested in writing a whole lot of new code in order to achieve readability. I just want to explore some simple ideas. When looking at the examples here, try to consider that there may be 10 or more additional tests which are not being shown. This will give you a better gauge as to whether the effort expended here is really worth it.

The Clean Up

ILoginView have User and Password properties that needs to return different values depending upon the test. To clean up the current implementation, we could do something over-the-top, like this:

// add this method to test class
private static ILoginView CreateLoginView
{
    get
    {
        return MockRepository.GenerateStub<ILoginView>();
    }
}

// add internal class to hold extension methods
internal static class when_user_is_logging_in_extensions
{
    public static ILoginView WithUser(this ILoginView view, string user)
    {
        view.Stub(x => x.User).Return(user);
        return view;
    }

    public static ILoginView AndPassword(this ILoginView view, string password)
    {
        view.Stub(x => x.Password).Return(password);
        return view;
    }
}

// Now, I have a readable fluent interface
ILoginView view = CreateLoginView.WithUser("BADUSER").AndPassword("BADPASSWORD");

Readable, sure, but seriously, that’s a lot of code. All of the convenience of using Rhino Mocks is lost. To compromise, I would probably just do something like this:

// in test class
private static ILoginView CreateLoginView(string withUser, string withPassword)
{
    ILoginView view = MockRepository.GenerateStub<ILoginView>();
    view.Stub(x => x.User).Return(withUser);
    view.Stub(x => x.Password).Return(withPassword);
    return view;
}

// in test
ILoginView view = CreateLoginView("BadUser", "BadPassword");

Here, I will let the method name, parameter names, and IntelliSense act as documentation. Like the last example, it requires a bit of code, too, but in this case ReSharper handles the Extract Method for me. Renaming CreateLoginView to create_login_view makes the IntelliSense story even better (in my opinion), but I will leave that alone for now.

For the login service, I will use the same technique:

// in test class
private static ILoginService CreateLoginService(bool shouldAuthenticate)
{
    var loginService = MockRepository.GenerateStub<ILoginService>();
    loginService.Expect(x => x.UserExists("", ""))
        .IgnoreArguments()
        .Return(shouldAuthenticate);
    return loginService;
}

// in test
ILoginService loginService = CreateLoginService(false);

To finish up, I will add a few extension methods by creating an internal static class at the bottom of my test file:

internal static class when_user_is_logging_in_extensions
{
    public static void PushOkButton(this ILoginView view)
    {
        view.Raise(x => x.TryLogin += null, view, EventArgs.Empty);
    }

    public static void ShouldBeClosed(this ILoginView view)
    {
        view.AssertWasCalled(x => x.Close());
    }
}

With all of the changes in place, my test now looks like this:

[Test]
public void only_three_login_attempts_are_allowed()
{
    ILoginView view = CreateLoginView("BadUser", "BadPassword");
    ILoginService loginService = CreateLoginService(false);

    LoginPresenter presenter = new LoginPresenter(loginService);
    presenter.Initialize(view);

    view.PushOkButton();
    view.PushOkButton();
    view.PushOkButton();
    
    view.ShouldBeClosed();
}

I am not advocating that anyone go to this trouble; context, preference, and discretion must be considered. However, I think there is great value in having readable tests. For some, the starting example might be perfectly readable. For others, not so much. As with everything, take what you like and leave the rest.

Application Extensibility and Embedded Scripting

jp — Mon, 18 May 2009 04:04:45 -0700

When we talk about application extensibility, we are often concerned with the structure of the code itself. Following known design principles and patterns and using techniques like inversion of control can be the foundation of a flexible, extensible, and testable code base. However, these concerns happen at compile time and are mostly static (plug-in style architectures being somewhat of an exception). In many large applications with complex business rules, there is often a need to modify a program while it is running. Searching “business rules engine” will give you no shortage of hits, but I think these types of solutions are, for the most part, not flexible enough. In this developer’s humble opinion, nothing is more flexible than code. So, if you can stop pretending that your end users “might want to change a thing or two on their own”, then you can stop pretending that code is a bad thing (I say this facetiously:) note to self: must write a rant about those who think code is bad).

I have written about how easy it is to compile C# at runtime before. I used this technique on a former project to create a “formula engine” for calculating bid-related things like mark-up, transportation costs, discounts, and so forth. I should note that these formulas were never meant to be written by end users, but rather, another developer. During one of several design sessions for this part of the application, we were made aware that formulas required a lot of context and that they could change rather frequently. Dynamic compilation proved to be a good solution and the foundation for the whole thing was coded in two days. There is nothing better than showing your client, who thought a feature would take 2 months, a working prototype in 2 days.

Embedding a Scripting Language

As it turns out, it is even easier (and more flexible) to embed a DLR language into a .NET application. My personal favorite is IronPython, but the following steps should be similar for other DLR languages. The first thing you need to do is references to the following assemblies, which are included with the DLR:

IronPython
IronPython.Modules
Microsoft.Scripting
Microsoft.Scripting.Core

Once you have added these references, it is relatively easy to start executing IronPython code. Here is a simple class that I used to test out some ideas for this article:

public class PyEval
{
    private ScriptEngine scriptEngine;

    public PyEval()
    {
        scriptEngine = Python.CreateEngine();
    }

    public object Execute(string yourPythonCode)
    {
        StringBuilder script = new StringBuilder();
        script.AppendLine("import clr");
        // additional imports would go here
        script.AppendLine(yourPythonCode);

        return scriptEngine.Execute(script.ToString());
    }
   
}

At the most basic level, the only thing required is an instance of ScriptEngine. Code can be executed by calling the Execute method. One item of interest is line #13. Here, the script is being modified before execution so that CLR extensions are available within the execution context. You will add additional imports to reference other parts of the .NET framework or assemblies within your application. The IronPython tutorial has plenty of examples on interacting with the CLR so I am going to skip that discussion.

Scope

Things get interesting when variables from your application are made available to the script. This is done using ScriptScope, and is a very straightforward process. Here is the class from the last example with a few modifications. You’ll have to use your imagination a bit to wash away the hard coding, but you should get the idea:

public class PyEval
{
    private ScriptEngine scriptEngine;
    private ScriptScope scriptScope;
    
    public PyEval()
    {
        scriptEngine = Python.CreateEngine();
        scriptScope = scriptEngine.CreateScope()
    }

    public object Execute(string yourPythonCode)
    {
        StringBuilder script = new StringBuilder();
        script.AppendLine("import clr");
        // additional imports would go here
        script.AppendLine(yourPythonCode);

        scriptScope.SetVariable("category", "drillbit");
        scriptScope.SetVariable("cost", 400);
        scriptScope.SetVariable("quantity", 1);
        
        return scriptEngine.Execute(script.ToString());
    }
    
}

Now, your script will have access to variables named category, cost, quantity:

def CalculateDiscount():
	if (category == "drillbit") and (cost * quantity > 399):
		return (cost * quantity) * .90
	else:
		return cost * quantity

CalculateDiscount()

What is not apparent thus far is how this is all hooked together within an application. What I have done in the past (since I have been doing rich clients exclusively) is to embed the SharpDevelop editor into my application, which supports IronPython. Scripts are loaded and saved to a database. Fundamentally, this is all there is to it.

The primary challenge is to define the parts of your application where you want to make scripting available. It’s always good to have a specific context and then write explicit code around that concept. One example that comes to mind is a pricing engine for an online retailer that calculates discounts based on certain conditions - which are constantly changing of course. This is a specific place in some application that has highly defined boundaries.

Another idea that I am planning on exploring in the near future is extending this concept to DSL’s. I haven’t done any investigations yet, but I am wondering if there would be any benefits to creating a DSL using IronPython and then making that DSL the primary scripting tool for an application. If the focus was tight enough, I imagine it would be possible to create something simple enough for a power user to engage in:)

Coding Dojo and Code Kata Resources

JP — Fri, 01 May 2009 05:45:00 -0700

Practice Material

I am hosting regular coding dojo's (group practice) and doing regular code kata's (solo practice). So, I am always in the need of new material.

Here is my current list of "go to" sites when I am looking for a programming challenge. If you know of any of others, please send them my way:

1. UVa Online Judge
2. TDD Problems
3. Ruby Quiz
4. Top Coder
5. Project Euler
6. CodeKata
7. SPOJ

Some other folks doing coding dojo's

If you want to read about coding dojo's, you are definitely going to want to check out these bloggers:

1. Mark Needham
2. Ivan Sanchez
3. Danilo Sato