Pencil.Unit and Micro Lightweight Unit Testing

Joe Armstrong of Erlang fame has the following to say on how he write unit tests Micro Lightweight Unit Testing
Here's a condenced retrace of his steps using F# and Pencil.Unit
Step 1) Write Micro Unit Test

Theory "Fib should work for known values from Wikipedia"
    [(0,0); (1, 1); (2, 1); (3, 2); (20, 6765)]
    (fun (n, e) -> Fib n |> Should Equal e)

Step 2) Implement Fib

let rec Fib = function
    | 0 -> 0
    | 1 -> 1
    | _ as n -> Fib(n - 1) + Fib(n - 2)

Step 3) Theorize about FastFib

Theory "FastFib should give same result as Fib"
    [0; 1; 2; 3; 25]
    (fun n -> FastFib n |> Should Equal (Fib n))

Step 4)Implement FastFib

let FastFib n =
    let rec loop n a b =
        match n with
        | 0 -> a
        | _ -> loop (n - 1) b (a + b)
    loop n 0 1

Fact about Pizza.

I find this test as amusing as it's silly:

#light

open Pencil.Unit

Fact "Pizza should have cheese."
    ("Pizza" |> Should (Contain "Cheese"))

And the output:

Pizza should have cheese. Failed with "Pizza" doesn't contain "Cheese".

Take your system for a SWiM

Marcus Ahnve voiced some intresting thoughts about 'should' and BDD in his post "Words dont come easy: MoSCov and BDD". Here's a few follow-up thoughts.

Since we write tests mainly for two reasons, to validate that we built something right, and often even more important, that we built the right thing. We often seek answers along the lines of, how does this class or compononent work? How do I use it? What precondition must be fullfilled? In short, we want answers.

I propse we learn our tests to SWiM!

S(hould)

The SUT should do something, the core of BDD. "The index page SHOULD have the title...". Great for starting conversations, discussion friendly since it's a quite soft expression that's easy to question with a simple "should it really?".

W(on't)

The SUT simply shouldn't do this. "Reading the same item twice WON'T cause multiple database calls." Good for thoose "Should not" moments.

i(nstruct)

How do I use this component? Learning tests, code samples and the like qualify. Capturing small scenarios as tests can be a nice way to spread knowledge on how to use the SUT, show best practice's and document often raised questions.

M(ust)

The SUT must always do this, "Authentication MUST fail if given the wrong username and password".

As Marcus points out in his comments "BDD is all about conversation" good conversations need strong and shared vocabularies.