Getting Started with FSpec

Published on June 11, 2014

This post will give a quick guide of how to get started with FSpec.

Generally, you would want to have unit tests separated from the production code that is under test, so start by creating a new F# project.

The FSpec core contains code that can discover and execute the tests in an assembly, so by far the easiest way to get started is to create a console application.

Visual studio new project dialog

Once you have created the application, add the FSpec NuGet package.

PM> Install-Package FSpec
Installing 'fspec 0.0.7'.
Successfully installed 'fspec 0.0.7'.
Adding 'fspec 0.0.7' to MySpecs.
Successfully added 'fspec 0.0.7' to MySpecs.

Your console application should have a Program.fs file. Edit it, and place the following code.

[<EntryPoint>]
let main argv =
    System.Reflection.Assembly.GetExecutingAssembly ()
    |> FSpec.TestDiscovery.runSingleAssembly

Set your start-up project to be your console application, and run your application. You should see the following:

Console output of running the empty specs

So let's start by writing the first spec. Add a file, MyFirstSpec.fs

module MyFirstSpec
open FSpec.Dsl
open FSpec.Matchers

let specs =
  describe "my first spec" [
    it "should start with a failing test" <| fun _ ->
      false.Should be.True
  ]

Run the specs, and you should see the following output

fspec-getting-started-first-failing-spec

The namespace FSpec.Core.Dsl contains the types necessary for building the the tests.

The namespace FSpec.Core.MatchersV3 contains the assertion framework. The types in this namespace will probably end up in FSpec.Core.Matchers, but at the time of writing, this namespace contains a deprecated matcher framework.

When the framework gets to a more mature state, these modules will probably be tagged with the AutoOpen attribute, so you only need to open FSpec.Core. But not having AutoOpen on these modules does allow for alternative or experimental variations to live in new modules, and thus not breaking existing code.

You can compile the specs to a .dll and use a dedicated test runner, but just wrapping the specs in a self hosting executable is a lot easier to begin with.

When you want to run the specs, just run the your start-up project. If you need to debug, just debug your start-up project.

Simple.

Happy spec'ing.

Previous: FSpec goes 0.1 (with Foq support)Next: Comparing FSpec to NSpec