FsUnit – Test Fsharp with Fsharp

February 11th | 2009

FsUnit – Test F# with F#

I recently spent some time putting together an F# lab with a series of unit tests designed to help teach the language. I started out with a set of Nunit tests in C#, but kept running head-first into type problems with the method signatures and return types. Another hiccup was that my VS 2008 C# code couldn’t see my F# code until I referenced the generated F# dll directly via Browsing. Adding a simple project reference didn’t work.

For example, here’s a simple F# function that returns the square of the input for any member with (*) defined and a C# assert based on it.

F# module:

#light

namespace Samples

module SampleOne =

let inline Square (x : ^x) = x * x;

C# code:

Assert.AreEqual(9, Samples.SampleOne.Square(3));

Seems simple enough, right? Except for the build error. “The Type arguments for method ‘Samples.SampleOne.Square<x,a>(x)’ cannot be inferred from the usage. Try specifying the type arguments explicitly.” What the compiler is telling us here is that we’re calling a generic function without specifying the types.

To make the compiler happy, we have to do the following instead:

Assert.AreEqual(9, Samples.SampleOne.Square<int, int>(3));

Elegant? No, not really. The syntactic magic that F# uses to allow us to infer types is not available within C#.

Here’s a simple F# function that calls ToString on all members of a list and returns it as a new list.

let ListToString x = List.map (fun x → x.ToString()) x;

Its signature in F# looks like: val WorkOnList : (`a → string list)

In C# … Microsoft.FSharp.Core.FSharpFunc<Microsoft.FSharp.Collections.FSharpList<b>, Microsoft.FSharp.Collections.FSharpList<string>> SampleOne.WorkOnList<a,b>(a x)

Confusing, at best. Luckily there’s a testing framework that avoids these issues and is designed for F#.

FsUnit to the Rescue

FsUnit is a library that defines a simple, easy-to-use testing syntax within F#. It currently works with NUnit, but is intended to work with MbUnit, xUnit, and MsTest in the future. It’s a breeze to set up, simply reference nunit.framework, FsUnit.NUnit, and include the FsUnit F# script that sets up the syntax.

Using FsUnit, we can describe our functions and write a test for them as follows:

#light
namespace Tests
open NUnit.Framework
open FsUnit

module module1 =
    let inline public Square x = x * x;

    [<TestFixture>]
    type ``Sample Tests`` ()=

        let WorkOnList x = List.map (fun (x) -> x.ToString()) x;
        let lame x = List.head x;

        [<Test>] member test.
         ``Test One`` ()=
            Square 5 |> should equal 25;
            Square 0 |> should equal 0;
            Square 1.5 |> should equal 2.25;
            WorkOnList [1;2;3;4;5] |> should equal ["1";"2";"3";"4";"5"]

Much more elegant and concise than the C# mess above. Spaces in test names are allowed—a feature I love. I’ve written far too many tests along the lines of ShouldCorrectlyDoOperationWhenValueAandValueBDoNotExceedValueC.

Languages typically use spaces to separate words instead of capitalization for a reason.

Keep in mind that this test syntax does not cause a compile time error if types do not match. For example, a function defined as let x = 0; does not cause a compile error when tested with x |> should equal “horse”.

In conclusion, I recommend giving FsUnit a try if you intend to test F# code. Test in the language you wrote the code in!

David Cooksey is a Senior .NET Developer at Thycotic Software, an agile software services and product development company based in Washington DC. Secret Server is our flagship password management software product.