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

What are the influences of Simula 67 on today’s programming languages? Is Simula 67 the most important language in the history of programming languages? What are the next big topics in programming languages? These were some of the questions discussed in the panel debate “Celebrating 40 years of language evolution: Simula 67 to the present and beyond” today at OOPSLA.

Parallelism revisited

It seems to me that tomorrow’s most important topic in programming will be related to parallelism. Both James Gosling and Anders Hejlsberg stated that the next important thing in programming will be address multithreading better. There are several drivers for this: first of all, we see that we are getting computers with more and more CPUs, and our current programming languages and inherently programs do a poor job taking advantage of this. Furthermore, applications are becoming more and more distributed, which also drives parallelism, timing and synchronization issues. I guess the fact that the programming language Erlang, created by Ericsson Computer Science Laboratory in the eighties, is getting attention these days, can be seen to emphasise this trend. Erlang has built-in support for concurrency.

Is functional programming the real deal?

Another topic touched upon by the panel, was the role of functional programs. OOPSLA being a conference built around object orientation, the crowd is of course a bit biased towards object oriented programs, pretty much like the rest of the world is. However, the current trend is that features from functional programs are finding their ways into object oriented languages like Java and C# (closures, higher order functions, etc.).
A question, then, is if functional programming will be the way of the future. Bertrand Mayer pointed out that functional programming will never be mainstream.
James Gosling went on to state that the problem with functional programming is that only a small part of the programming community understands it. Furthermore, Guy Steele pointed out that functional programming avoids the notion of state, which is a notion that will get ever more important as applications become distributed.

Programming: what can we do better?

One important topic in our field today is what we can do better to cope with the ever incresing complexity in software. One thing that Anders Hejlsberg pointed out, as that today’s programming focuses too much on the ‘how’, and too little on the ‘what’. Too much focus on ‘what’ gives too much complexity. Furthermore, Ole Lehrmann Madsen pointed out that there are too many papers at this conference about ‘adding x to Java’. Instead, we should think more out of the box to find new paradigms that can bring us a leap forward in the field of computer programming. Easier said than done, I guess… Going back to the topic of concurrency, Guy Steele pointed out that the dependency on the stack is the biggest problem for concurrency in today’s programming languages. This reminds me of Gregor Hohpe’s statement in the workshop I attended on Monday, that “SOA is like programming without a call stack”.