Mark Needham

Dermot and I were doing a bit of work on a mini testing DSL that we've been writing to try and make some of our interaction tests a bit more explicit and one of the things that we wanted to do was find out which method was being called on one of our collaborators.

We have a stub collaborator which gets injected into our system under test. It looks roughly like this:

public class StubCollaborator : IGotForcedToCollaborate
{
	public double Method1()
	{
		return CannedValue();
	}
 
	public double Method2()
	{
		return CannedValue();
	}
 
	private double CannedValue()
	{
		return 10;
	}
 
}

We wanted to try and capture which of the methods on that object had been called by our system under test and then assert on that value from our test.

While trying to work out how to do this we came across the 'StackTrace' object. We use it like so to work out which public method on that object has been called:

public class StubCollaborator : IGotForcedToCollaborate
{
	private MethodBase methodCalled;
 
	..
 
	private double CannedValue()
	{
		methodCalled =  new StackTrace().GetFrames()
                			.Select(f =>f.GetMethod())
                			.Where(m => m.DeclaringType.Name == GetType().Name)
                			.Where(m => m.IsPublic)
                			.First()
		return 10;
	}
 
	public string GetMethodCalled()
	{
		return methodBase.Name;
	}	
 
}

We needed to only find the public methods because 'CannedValue' was showing up on the stack trace and since it's private this was an easy way to exclude it.

I'm sure there are other ways to get this type of information but we were able to solve our problem really quickly with this solution.

A few weeks ago we had some C# code around calcuations which had got a bit too imperative in nature.

The code looked roughly like this:

public class ACalculator
{
	public double CalculateFrom(UserData userData)
	{
		if(userData.Factor1 == Factor1.Option1)
		{
			return 1.0;
		}
 
		if(userData.Factor2 == Factor2.Option3)
		{
			return 2.0;
		}
 
		if(userData.Factor3 == Factor3.Option2)
		{
			return 3.0
		}
		return 0.0;
	}
}

I think there should be a more object oriented way to write this code whereby we push some of the logic onto the 'UserData' object but it struck me that it reads a little bit like pattern matching code you might see in F#.

I decided to drive the code to use a dictionary which would store functions representing each of the conditions in the if statements:

public class ACalculator
{
	private Dictionary<Func<UserData, bool>, double> calculations;
 
	public ACalculator()
	{
    		calculations = new Dictionary<Func<UserData,bool>,double>
                       {
                           {u => u.Factor1 == Factor1.Option1, 1.0},
                           {u => u.Factor2 == Factor2.Option3, 2.0},                                       
                           {u => u.Factor3 == Factor3.Option2, 3.0}                                 
                       };	
	}	
 
	public double CalculateFrom(UserData userData)
	{
    		var calculation = calculations.Keys.FirstOrDefault(calc => calc(userData));
    		if(calculation != null)
    		{
        		return calculations[calculation];
    		}
 
    		return 0.0;
	}
}

It's less readable than it was before and it's not obvious that the adding of the functions to the dictionary needs to be in that order in order for it to work.

I've simplified the real example a bit to show the idea but I don't think it works as the best abstraction in this situation either way although it was an interesting experiment.

A problem we had to solve on my current project is how to handle form submission where the user can click on a different button depending whether they want to go to the previous page, save the form or go to the next page.

An imperative approach to this problem might yield code similar to the following:

public class SomeController
{
	public ActionResult TheAction(string whichButton, UserData userData)
	{
		if(whichButton == "Back")
		{
			// do the back action
		}
		else if(whichButton == "Next")
		{
			// do the next action
		}
		else if(whichButton == "Save")
		{
			// do the save action
		}
 
		throw Exception("");
	}
}

A neat design idea which my colleague Dermot Kilroy introduced on our project is the idea of using a dictionary to map to the different actions instead of using if statements.

public class SomeController
{
	private Dictionary<string, Func<UserData,ActionResult>> handleAction = 
		new Dictionary<string, Func<UserData,ActionResult>>
		{ { "Back", SaveAction },
		  { "Next", NextAction },
		  { "Save", SaveAction } };
 
	public ActionResult TheAction(string whichButton, UserData userData)
	{
		if(handleAction.ContainsKey(whichButton))
		{
			return handleAction[whichButton](userData);
		}
 
		throw Exception("");
	}
 
	private ActionResult NextAction(UserData userData)
	{
		// do cool stuff
	}
}

It's quite similar in a way to a problem we had on another project where we needed to deal with user inputs and then create an object appropriately.

The way we have to read the code is a bit more indirect than with the original approach since you now need to click through to the individual methods for each action.

On the other hand I like the fact that we don't have if statements all over the place anymore.

* Updated * – updated to take Dhananjay Goyani's comments into account

I recently came across the idea of tacit programming which is described as such:

Tacit programming is a programming paradigm in which a function definition does not include information regarding its arguments, using combinators and function composition (but not λ-abstraction) instead of variables.

The simplicity behind this idea allows its use on several programming languages, such as J programming language and APL and especially in stack or concatenative languages, such as PostScript, Forth, Joy or Factor. Outside of the APL and J communities, tacit programming is referred to as point-free style.

I realised that this approach quite closely describes what I've been trying to drive towards in my most recent playing around with F# and it's actually quite fun trying to drive any intermediate state or storing of data in variables out of a program and just relying completely on function composition and higher order functions.

It seems like we need to define the signatures of some of the functions more explicitly but once we have a group of these functions we can combine them quite effectively elsewhere in our program.

Moving towards function composition

I've been trying to do this with the F# test builder that I've been working on and in a few cases it's helped to reduce the amount of code required.

The build function originally read roughly like this:

and build (t:Type) = 
     let shortestConstructor = getShortestConstructor t
 
     shortestConstructor |>
     invokeWith (fun c -> getParameters c |> Array.map (fun p -> valueFor { Type = p.ParameterType; Name = p.Name })) |>
     andApply (fun t -> getWriteableProperties t |> Array.iter(setValueOn t))

In order to drive that code toward a 'point-free style' we need to make use of the function composition operator which allows us to get the code to the stage where we don't need to specify the signature of 'build', it can be inferred:

and build = getShortestConstructor >>
            invokeWith (getParameters >> Array.map (fun p -> valueFor { Type = p.ParameterType; Name = p.Name })) >>
            andApply (fun t -> getWriteableProperties t |> Array.iter(setValueOn t))

I think that code is pretty much identical to the first version but I'm getting the following warning message pointing to the 'valueFor' call on line 2:

Warning	1	This and other recursive references to the object(s) being defined will be checked for initialization-soundness at runtime through the use of a delayed reference. This is because you are defining one or more recursive objects, rather than recursive functions. This warning may be suppressed by using #nowarn "40" or --nowarn 40.	C:\Playbox\yab\yab\Builder.fs	40	66	yab

I can't figure out how I can change the code to get rid of that warning. I also haven't worked out whether it's possible to fix the 'andApply' line so that we can use functional composition throughout.

It would be cool if it could written in such a way that 't' wouldn't have to be explicitly specified. I can't quite figure out how to do it because I need to call 'getWriteableProperties' and then iterate through that sequence and set a value on 't' using each one.

Is there a way to write that bit of code so that 't' could be inferred?

Some functions need to define signatures?

In order to write a 'build' function which heavily uses functional composition I've pulled out several helper functions which all currently explicitly define their signatures:

    let getWriteableProperties t = t.GetType().GetProperties() |> Array.filter (fun p -> p.CanWrite)
 
    let invokeWith f (aConstructor:ConstructorInfo) = f(aConstructor) |> aConstructor.Invoke

If we want to call C# libraries like this then I don't think we have a choice but to explicitly define function signatures. It is possible to push the place at which we need to do this by writing F# functions to wrap those C# method calls but at some stage we'll explicitly define a function signature:

let getWriteableProperties = getTypeProperties >> Array.filter writeableProperty

where the extra helper functions are defined like so:

let getTypeProperties t = t.GetType().GetProperties()
let writeableProperty (p:PropertyInfo) = p.CanWrite

I can't see a way around this so again I'd be interested if there is one. I don't think it's a problem anyway, just intrigued how far their programming approach can be taken.

I spent a bit of time over the weekend coding a simple generic builder for test objects in F# and I noticed that although there were similarity with the ways I drive code in C# or Java my approach didn't seem to be exactly the same.

I've previously written about the importance of getting quick feedback when programming and how I believe that this can often be achieved faster by using the REPL rather than unit testing.

Still driving from the outside in

This time I decided to apply some of my recent learnings on the value of driving from the outside in so I started by writing an acceptance test which described the fluent interface of the code at a high level.

I want to use the builder from C# code so I was driving the code from C# tests:

[Test]
public void ShouldCreateAFoo()
{
	var foo = Build.A<Foo>().Build();
 
	Assert.That(foo.Bar, Is.EqualTo("Bar"));
}

I wrote enough code to make that test compile at which stage the test was failing with a null reference exception because I hadn't instantiated 'Foo' yet.

At this stage if I was coding in C# I would probably work out what object I needed to create to do that and then I would write a test directly against that object and then write the code to make that pass.

In this case I didn't do that but instead I had a rough idea of the functions that I needed to glue together to get that test to pass. I just wrote those functions and combined them together without writing any tests against those individual functions.

I extended my initial test to cover all the different types that are being used by the objects in our code base and then I added the code to make the new type pass.

Approach to learning an API

Since it's reflection code and I don't know those APIs that well I spent a bit of time tinkering in the REPL until I knew which methods I needed to call.

If I was writing C# then I'd have probably spent less time trying out different methods and more time reading through the list of available methods before choosing the one that I wanted.

I wrote quite messy code initially until I had the first test passing and then I went back and tidied it up so that it was a bit more readable.

At this stage common functions started to reveal themselves and it made sense to have some unit tests directly against those as documentation if nothing else. The tests were all immediately green so those bits of code weren't test driven at that level.

Do we need really granular tests in F#?

My overall feeling at the moment is that while it's useful to have tests around code written in F#, we don't need to go as granular with our tests as we might do in C#.

Due to the conciseness of the language it's often so obvious that the code written is correct that I don't think tests at the functional level would add that much value. Equally I'm not necessarily convinced that the design would be any different if the individual functions were test driven.

I found the high level test gave me enough protection for any changes that I wanted to make and it did protect me a couple of times when I made breaking changes.

Having said all that, I'm still only writing toy code so it would be interesting to see if my approach would be any different if I was working on an F# application with a team of other developers.

A couple of days I wrote about a 'returning' function that I'd written to simplify a bit of F# code that I've been working on.

It's defined like so:

let returning t f = f(t); t

And can then be used like this:

let build (t:Type) =
    returning (Activator.CreateInstance(t)) (fun t -> 
        t.GetType().GetProperties() |> Array.iter (fun p -> p.SetValue(t, createValueFor p, null)))

While I quite like this function it didn't quite feel like idiomatic F# to me.

With idiomatic F# we would tend to design our functions in such a way that we can pipe data through a series of them by making use of the forward or function composition operators.

With that idea in mind I decided to try switching the arguments to 'returning' around and renaming it so that the code would read more naturally:

let andApply f t = f(t); t

let build (t:Type) =
    Activator.CreateInstance(t) |>
    andApply (fun t ->  t.GetType().GetProperties() |> Array.iter (fun p -> p.SetValue(t, createValueFor p, null)))

We partially apply the 'andApply' function to create a new function which takes in a type which is provided on the left hand side of the '|>' operator.

I think this now reads better than the original version.

What I find interesting is that when writing functions which I intend to be used like this the way I name them is different and the name only makes sense if it's used in that context.

Using the 'andApply' function on its own without making use of partial function application wouldn't read as cleanly as it does at the moment.

I've been playing around a bit with Iron Ruby and cucumber following Rupak Ganguly's tutorial and I tried to change the .NET example provided in the 0.4.2 release of cucumber to call a class wrapping Castle's WindsorContainer.

The feature file now looks like this:

# 'MyAssembly.dll' is in the 'C:/Ruby/lib/ruby/gems/1.8/gems/cucumber-0.6.4/examples/cs' folder
require 'MyAssembly'
...
Before do
  @container = Our::Namespace::OurContainer.new.Container
end

The class is defined roughly like this:

public class OurContainer : IContainerAccessor
    {
        private WindsorContainer container = new WindsorContainer();
 
        public SwintonContainer()
        {
            container.RegisterControllers(Assembly.GetExecutingAssembly()).AddComponent<IFoo, Foo>();
           // and so on
        }
 
        public IWindsorContainer Container
        {
            get { return container; }
        }
    }

When I tried to run the feature like so:

icucumber features

I kept getting the following error:

uninitialized constant Our::Namespace::OurContainer (NameError)
C:/Ruby/lib/ruby/gems/1.8/gems/cucumber-0.6.4/examples/cs/features/step_definitons/calculator_steps.rb:13:in `Before'

I've come across a few posts where people described the same error and they all suggested that IronRuby was unable to find the class that I was trying to call in the code.

I decided to try calling another class from the assembly to see if that was the problem but that worked fine so there wasn't a problem with locating the class.

Somewhat by coincidence I was looking at the assembly again in Reflector and tried to look at the constructor of the 'OurContainer' class and was asked to give the location of the 'Castle.Windsor' assembly which it uses internally.

I didn't have that assembly or any of its dependencies in the 'C:/Ruby/lib/ruby/gems/1.8/gems/cucumber-0.6.4/examples/cs' folder but once I'd included those it all worked fine again!

I wrote previously about how we've been working on some calculations on my current project and one thing we've been trying to do is write this code in a fairly declarative way.

Since we've been test driving the code it initially started off being quite imperative and looked a bit like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

public class TheCalculator
{
	...
	public double CalculateFrom(UserData userData)
	{
		return Calculation1(userData) + Calculation2(userData) + Calculation3(userData);
	}
 
	public double Calculation1(UserData userData)
	{
		// do calculation stuff here
	}
 
	public double Calculation2(UserData userData)
	{
		// do calculation stuff here
	}
	...
}

What we have on line 7 is a series of calculations which we can put in a collection and then sum together:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

public class TheCalculator
{
	...
	public double CalculateFrom(UserData userData)
	{
		var calculations = new Func<UserData, double>[] { Calculation1, Calculation2, Calculation3 };
 
		return calculations.Sum(calculation => calculation(userData));
	}
 
	public double Calculation1(UserData userData)
	{
		// do calculation stuff here
	}
	...
}

We can pull out a 'Calculation' delegate to make that a bit more readable:

public class TheCalculator
{
	private delegate double Calculation(UserData userData);
 
	public double CalculateFrom(UserData userData)
	{
		var calculations = new Calculation[] { Calculation1, Calculation2, Calculation3 };
 
		return calculations.Sum(calculation => calculation(userData));
	}
	...	
}

One of the cool things about structuring the code like this is that if we want to add a new Calculation we can just go to the end of the array, type in the name of the method and then Resharper will create it for us with the proper signature.

We eventually came across some calculations which needed to be subtracted from the other ones, which seems like quite an imperative thing to do!

Luckily Christian saw a way to wrap these calculations in a 'Subtract' function so that we could stay in declarative land:

public class TheCalculator
{
	private delegate double Calculation(UserData userData);
 
	public double CalculateFrom(UserData userData)
	{
		var calculations = new [] { Calculation1, Calculation2, Calculation3, Subtract(Calculation4) };
 
		return calculations.Sum(calculation => calculation(userData));
	}
	...	
	public Calculation Subtract(Calculation calculation)
	{
		return userData => calculation(userData) * -1;
	}
}

Having a method which explicitly has the 'Calculation' signature allows us to remove it from the array declarative which is pretty neat.

We can also change the method signature of 'Subtract' to take in a variable number of calculations if we need to:

public class TheCalculator
{
	...	
	public double CalculateFrom(UserData userData)
	{
		var calculations = new [] { Calculation1, Calculation2, Calculation3, Subtract(Calculation4, Calculation5) };
 
		return calculations.Sum(calculation => calculation(userData));
	}
 
	public Calculation Subtract(params Calculation[] calculations)
	{
		return userData => calculations.Sum(calculation =>  calculation(userData)) * -1;
	}
}

The other nice thing about coding it this way is that we ran into a problem where when we fed real data through the code we were getting the wrong values returned and we wanted to understand where it was falling down.

We could easily temporarily add in a 'Console.WriteLine' statement like this to help us out:

public class TheCalculator
{
	...	
	public double CalculateFrom(UserData userData)
	{
		var calculations = new [] { Calculation1, Calculation2, Calculation3, Subtract(Calculation4, Calculation5) };
 
		return calculations
			.Select(calculation =>
					{
						Console.WriteLine(calculation.Method.Name + " = " + calculation(userData));
						return calculation;
					})
			.Sum(calculation => calculation(userData));
	}
	...
}

It then printed the results down the page like so:

Calculation1: 23.34
Calculation2: 45.45
...

One of the problems that I've frequently run into when writing C# code in a more functional way is that we can often end up with 'Funcs' all over the place which don't really describe what concept they're encapsulating.

We had some code similar to this where it wasn't entirely obvious what the Func being stored in the dictionary was actually doing:

public class Calculator
{
	private Dictionary<string, Func<double, double, double>> lookups = new Dictionary<string, Func<double, double, double>>();
 
	public Blah()
	{
		lookups.Add("key", (input1, input2) => (input1 * 0.1) / input2);
	}
	...
}

Christian pointed out that we can create a named delegate (something I had completely forgotten!) so that it's a bit more obvious what exactly we're storing in the dictionary just by looking at the code.

We'd then end up with this code:

public class Calculator
{
	private delegate double PremiumCalculation(double input1, double input2);
 
	private Dictionary<string, PremiumCalculation> lookups = new Dictionary<string, PremiumCalculation >();
 
	public Calculator()
	{
		lookups.Add("key", (input1, input2) => (input1 * 0.1) / input2);
	}
	...
}

Now it's pretty clear from just reading the declaration of 'lookups' what it's being used for without needing to go further into the code to understand that.

This is just a simple example but the problem becomes more obvious the more angle brackets we end up with in our dictionary definition and pulling those Funcs out makes the code much easier to understand.

We've been writing quite a bit of code on my current project trying to encapsulate user selected values from drop down menus where we then want to go and look up something in another system based on the value that they select.

Essentially we have the need for some of the things that a Java Enum would give us but which a C# one doesn't!

Right now we have several classes similar to the following in our code base to achieve this:

public class CustomerType
{
    public static readonly CustomerType Good = new CustomerType("Good", "GoodKey");
    public static readonly CustomerType Bad = new CustomerType("Bad", "BadKey");
 
    private readonly string displayValue;
    private readonly string key;
    private static readonly CustomerType[] all = new[] { Good, Bad };
 
    private CustomerType(string displayValue, string key)
    {
        this.displayValue = displayValue;
        this.key = key;
    }
 
    public static CustomerType From(string customerType)
    {
        return all.First(c => c.displayValue == customerType);
    }
 
    public static string[] Values
    {
        get { return all.Select(c => c.DisplayValue).ToArray(); }
    }
 
    public string DisplayValue
    {
        get { return displayValue; }
    }
 
    public string Key
    {
        get { return key; }
    }
}

To get values to display in drop downs on the screen we call the following property in our controllers:

CustomerType.Values

And to map from user input to our type we do this:

CustomerType.From("Good")

Right now that will blow up if you trying to parse a value that doesn't have an instance associated with it.

Christian came up with the idea of storing each of the public static fields in an array and then using 'First' inside the 'From' method to select the one that we want.

We previously had a somewhat over complicated dictionary with the display value as the key and type as the value and looked it up that way.

So far this does all that we need to do and the only annoying thing is that if we add a new instance then we need to manually add it to the 'all' array.

An alternative would be to do that using reflection which I think would work but it's simple enough like this so we haven't taken that approach yet.