# Rash thoughts about .NET, C#, F# and Dynamics NAV.

## Saturday, 24. April 2010

### Solving KataYahtzee with F# and NaturalSpec

Filed under: F#,Informatik,Kata — Steffen Forkmann at 19:04 Uhr

Today I├óŌé¼Ōäóm starting a new blog post series about solving code katas in F# and with the help of my NaturalSpec project. A code kata is a programming exercise which helps to improve your skills through practice and repetition. In this series we want to use the Test Driven Development TDD approach which means in the context of NaturalSpec that we have to write our specs before we implement the algorithm.

#### Problem Description

├óŌé¼┼ōThe game of yahtzee is a simple dice game. Each round, each player rolls five six sided dice. The player may choose to reroll some or all of the dice up to three times (including the original roll). The player then places the roll at a category, such as ones, twos, sixes, pair, two pairs etc. If the roll is compatible with the score, the player gets a score for this roll according to the rules. If the roll is not compatible, the player gets a score of zero for this roll.

The kata consists of creating the rules to score a roll in any of a predefined category. Given a roll and a category, the final solution should output the score for this roll placed in this category.├óŌé¼┬Ø

##### Category 1 ├óŌé¼ŌĆ£ Ones, Twos, Threes, Fours, Fives, Sixes

├óŌé¼┼ōOnes, Twos, Threes, Fours, Fives, Sixes: The player scores the sum of the dice that reads one, two, three, four, five or six, respectively. For example, 1, 1, 2, 4, 4 placed on "fours" gives 8 points.├óŌé¼┬Ø

After reading this category description we could come up with the following spec:

module Yahtzee.Specs

open NaturalSpec

let placed_on category list =

printMethod category

calcValue category list

[<Scenario>]

let “Given 1,1,2,4,4 placed on "fours" gives 8 points.“ () =

Given (1, 1, 2, 4, 4)

|> When (placed_on Fours)

|> It should equal 8

|> Verify

Since we really want to implement six different categories we should also add some more scenarios like this one:

[<Scenario>]

let “Given 1,1,6,4,6 placed on "sixes" gives 12 points.“ ()=

Given (1, 1, 6, 4, 6)

|> When (placed_on Sixes)

|> It should equal 12

|> Verify

// …

Now we have some specs but they will all fail since we don├óŌé¼Ōäót have anything implemented yet. So we have to come up with a model of dice rolls and categories. As the specs suggests we model the dice roll as a tuple of ints and the category as a discriminated union:

module Yahtzee.Model

type Roll = int * int * int * int * int

type Category =

| Ones

| Twos

| Threes

| Fours

| Fives

| Sixes

The tuple is a natural choice for the dice roll, but for easier calculation we add a helper function which converts it into a list. This allows use to use the standard list functions and therefore summing the values becomes trivial:

let toList (roll:Roll) =

let a,b,c,d,e = roll

[a;b;c;d;e]

let sumNumber number =

Seq.filter ((=) number)

>> Seq.sum

let calcValue category roll =

let list = toList roll

match category with

| Ones   -> sumNumber 1 list

| Twos   -> sumNumber 2 list

| Threes -> sumNumber 3 list

| Fours  -> sumNumber 4 list

| Fives  -> sumNumber 5 list

| Sixes  -> sumNumber 6 list

Now we can run our scenarios with any NUnit runner. I├óŌé¼Ōäóm using the default NUnit GUI runner here, which gives me a picture like this: ##### Category 2 ├óŌé¼ŌĆ£ Pair

├óŌé¼┼ōPair: The player scores the sum of the two highest matching dice. For example, 3, 3, 3, 4, 4 placed on "pair" gives 8.├óŌé¼┬Ø

The kata description gives us some new scenarios. As seen above we should specify them before writing the code.

[<Scenario>]

let “Given 3,3,3,4,4 placed on "pair" gives 8.“ () =

Given (3, 3, 3, 4, 4)

|> When (placed_on Pair)

|> It should equal 8

|> Verify

[<Scenario>]

let “Given 5,3,5,4,4 placed on "pair" gives 10.“ () =

Given (5, 3, 5, 4, 4)

|> When (placed_on Pair)

|> It should equal 10

|> Verify

[<Scenario>]

let “Given 1,2,3,4,5 placed on "pair" gives 0.“ () =

Given (1, 2, 3, 4, 5)

|> When (placed_on Pair)

|> It should equal 0

|> Verify

Since we use a new category we now have to extend our model and the calcValue function:

type Category =

| Ones

// …

| Sixes

| Pair

// …

let sumAsPair list number =

let numberCount =

list

|> Seq.filter ((=) number)

|> Seq.length

if numberCount >= 2 then 2 * number else 0

let calcValue category roll =

let list = toList roll

match category with

| Ones   -> sumNumber 1 list

// …

| Sixes  -> sumNumber 6 list

| Pair   ->

[1..6]

|> Seq.map (sumAsPair list)

|> Seq.max

##### Category 3 – Two pairs

├óŌé¼┼ōTwo pairs: If there are two pairs of dice with the same number, the player scores the sum of these dice. If not, the player scores 0. For example, 1, 1, 2, 3, 3 placed on "two pairs" gives 8.├óŌé¼┬Ø

[<Scenario>]

let “Given 1,1,2,3,3 placed on "two pair" gives 8.“ () =

Given (1, 1, 2, 3, 3)

|> When (placed_on TwoPair)

|> It should equal 8

|> Verify

[<Scenario>]

let “Given 1,6,6,3,3 placed on "two pair" gives 18.“ () =

Given (1, 6, 6, 3, 3)

|> When (placed_on TwoPair)

|> It should equal 18

|> Verify

[<Scenario>]

let “Given 1,1,2,4,3 placed on "two pair" gives 0.“ () =

Given (1, 1, 2, 4, 3)

|> When (placed_on TwoPair)

|> It should equal 0

|> Verify

Implementing this category is a little bit tricky but with the help of our Pair function and some more standard sequence combinators we can get our spec green:

type Category =

| Ones

// …

| TwoPair

let allPairs =

[for i in 1..6 do

for j in 1..6 -> i,j]

let calcValue category roll =

// …

| TwoPair   ->

allPairs

|> Seq.filter (fun (a,b) -> a <> b)

|> Seq.map (fun (a,b) ->

let a’ = sumAsPair list a

let b’ = sumAsPair list b

if a’ = 0 || b’ = 0 then 0 else a’ + b’)

|> Seq.max

##### Category 4 – Three of a kind

├óŌé¼┼ōThree of a kind: If there are three dice with the same number, the player scores the sum of these dice. Otherwise, the player scores 0. For example, 3, 3, 3, 4, 5 places on "three of a kind" gives 9.├óŌé¼┬Ø

[<Scenario>]

let “Given 3,3,3,4,5 placed on "three of a kind" gives 9“()=

Given (3, 3, 3, 4, 5)

|> When (placed_on ThreeOfAKind)

|> It should equal 9

|> Verify

[<Scenario>]

let “Given 3,4,3,4,5 placed on "three of a kind" gives 0“()=

Given (3, 4, 3, 4, 5)

|> When (placed_on ThreeOfAKind)

|> It should equal 0

|> Verify

Now it is time to refactor our code. The sumAsPair function should be extended to a sumAsTuple function:

type Category =

| Ones

// …

| ThreeOfAKind

let sumAsTuple value list number =

let numberCount =

list

|> Seq.filter ((=) number)

|> Seq.length

let takeBestTuple value list =

[1..6]

|> Seq.map (sumAsTuple value list)

|> Seq.max

if numberCount >= value then value * number else 0

let calcValue category roll =

// …

| Pair   -> takeBestTuple 2 list

| TwoPair   ->

allPairs

|> Seq.filter (fun (a,b) -> a <> b)

|> Seq.map (fun (a,b) ->

let a’ = sumAsTuple 2 list a

let b’ = sumAsTuple 2 list b

if a’ = 0 || b’ = 0 then 0 else a’ + b’)

|> Seq.max

| ThreeOfAKind ├óŌé¼ŌĆ£> takeBestTuple 3 list

##### Category 5 – Four of a kind

├óŌé¼┼ōFour of a kind: If there are four dice with the same number, the player scores the sum of these dice. Otherwise, the player scores 0. For example, 2, 2, 2, 2, 5 places on "four of a kind" gives 8.├óŌé¼┬Ø

[<Scenario>]

let “Given 2,2,2,2,5 placed on "four of a kind" gives 8“ ()=

Given (2, 2, 2, 2, 5)

|> When (placed_on FourOfAKind)

|> It should equal 8

|> Verify

[<Scenario>]

let “Given 2,6,2,2,5 placed on "four of a kind" gives 0“ ()=

Given (2, 6, 2, 2, 5)

|> When (placed_on FourOfAKind)

|> It should equal 0

|> Verify

With the help of the takeBestTuple function this becomes trivial:

type Category =

| Ones

// …

| FourOfAKind

let calcValue category roll =

// …

| FourOfAKind  -> takeBestTuple 4 list

##### Category 6 ├óŌé¼ŌĆ£ Small straight

├óŌé¼┼ōSmall straight: If the dice read 1,2,3,4,5, the player scores 15 (the sum of all the dice), otherwise 0.├óŌé¼┬Ø

[<Scenario>]

let “Given 1,2,3,4,5 placed on "Small Straight" gives 15“()=

Given (1,2,3,4,5)

|> When (placed_on SmallStraight)

|> It should equal 15

|> Verify

[<Scenario>]

let “Given 1,2,5,4,3 placed on "Small Straight" gives 15“()=

Given (1,2,5,4,3)

|> When (placed_on SmallStraight)

|> It should equal 15

|> Verify

[<Scenario>]

let “Given 1,2,6,4,3 placed on "Small Straight" gives 0“()=

Given (1,2,6,4,3)

|> When (placed_on SmallStraight)

|> It should equal 0

|> Verify

As in all the above scenarios we don├óŌé¼Ōäót assume any specific order in our rolls but for this category it is easier to test if the data is sorted:

type Category =

| Ones

// …

| SmallStraight

let calcValue category roll =

// …

| SmallStraight ->

match list |> List.sort with

| [1;2;3;4;5] -> 15

| _ -> 0

##### Category 7 ├óŌé¼ŌĆ£ Large straight

├óŌé¼┼ōLarge straight: If the dice read 2,3,4,5,6, the player scores 20 (the sum of all the dice), otherwise 0.├óŌé¼┬Ø

[<Scenario>]

let “Given 2,3,4,5,6 placed on "Large Straight" gives 20“()=

Given (2,3,4,5,6)

|> When (placed_on LargeStraight)

|> It should equal 20

|> Verify

[<Scenario>]

let “Given 6,2,5,4,3 placed on "Large Straight" gives 20“()=

Given (6,2,5,4,3)

|> When (placed_on LargeStraight)

|> It should equal 20

|> Verify

[<Scenario>]

let “Given 1,2,6,4,3 placed on "Large Straight" gives 0“()=

Given (1,2,6,4,3)

|> When (placed_on LargeStraight)

|> It should equal 0

|> Verify

Of course the implementation is exactly the same as for the small straight:

type Category =

| Ones

// …

| LargeStraight

let calcValue category roll =

// …

| LargeStraight ->

match list |> List.sort with

| [2;3;4;5;6] -> 20

| _ -> 0

##### Category 8 ├óŌé¼ŌĆ£ Full house

├óŌé¼┼ōFull house: If the dice are two of a kind and three of a kind, the player scores the sum of all the dice. For example, 1,1,2,2,2 placed on "full house" gives 8. 4,4,4,4,4 is not "full house".├óŌé¼┬Ø

[<Scenario>]

let “Given 1,1,2,2,2 placed on "full house" gives 8.“ () =

Given (1,1,2,2,2)

|> When (placed_on FullHouse)

|> It should equal 8

|> Verify

[<Scenario>]

let “Given 4,4,4,4,4 placed on "full house" gives 0.“ () =

Given (4,4,4,4,4)

|> When (placed_on FullHouse)

|> It should equal 0

|> Verify

[<Scenario>]

let “Given 1,1,2,3,2 placed on "full house" gives 0.“ () =

Given (1,1,2,3,2)

|> When (placed_on FullHouse)

|> It should equal 0

|> Verify

Implementing the FullHouse category is easy if we reuse our solutions to the Two pairs category:

type Category =

| Ones

// …

| FullHouse

let takeBestCombo value1 value2 list =

allPairs

|> Seq.filter (fun (a,b) -> a <> b)

|> Seq.map (fun (a,b) ->

let a’ = sumAsTuple value1 list a

let b’ = sumAsTuple value2 list b

if a’ = 0 || b’ = 0 then 0 else a’ + b’)

|> Seq.max

let calcValue category roll =

// …

| TwoPair   -> takeBestCombo 2 2 list

// …

| FullHouse   -> takeBestCombo 2 3 list

##### Category 9 ├óŌé¼ŌĆ£ Yahtzee

├óŌé¼┼ōYahtzee: If all dice are the have the same number, the player scores 50 points, otherwise 0.├óŌé¼┬Ø

Here we can use NaturalSpec’s ScenarioTemplates in order to specify all Yahtzees:

[<ScenarioTemplate(1)>]

[<ScenarioTemplate(2)>]

[<ScenarioTemplate(3)>]

[<ScenarioTemplate(4)>]

[<ScenarioTemplate(5)>]

[<ScenarioTemplate(6)>]

let “Given n,n,n,n,n placed on "Yahtzee" gives 50.“ n =

Given (n,n,n,n,n)

|> When (placed_on Yahtzee)

|> It should equal 50

|> Verify

[<Scenario>]

let “Given 1,1,1,2,1 placed on "Yahtzee" gives 50.“ () =

Given (1,1,1,2,1)

|> When (placed_on Yahtzee)

|> It should equal 0

|> Verify

The implementation is pretty easy:

type Category =

| Ones

// …

| Yahtzee

let calcValue category roll =

// …

| Yahtzee ->

let a,b,c,d,e = roll

if a = b && a = c && a = d && a = e then 50 else 0

##### Category 10 ├óŌé¼ŌĆ£ Chance

├óŌé¼┼ōChance: The player gets the sum of all dice, no matter what they read.├óŌé¼┬Ø

[<Scenario>]

let “Given 1,1,1,2,1 placed on "Chance" gives 6.“ () =

Given (1,1,1,2,1)

|> When (placed_on Chance)

|> It should equal 6

|> Verify

[<Scenario>]

let “Given 1,6,1,2,1 placed on "Chance" gives 11.“ () =

Given (1,6,1,2,1)

|> When (placed_on Chance)

|> It should equal 11

|> Verify

This seems to be the easiest category as we only have to sum the values:

type Category =

| Ones

// …

| Chance

let calcValue category roll =

// …

| Chance -> List.sum list

##### Conclusion

We used a lot of F#├óŌé¼Ōäós sequence combinators, pattern matching and discriminated unions in this kata. I think this shows that F# is very well suited for such a problem and with NaturalSpec we can easily use a TDD/BDD approach.

The complete source code can be found in the NaturalSpec repository.

If you want to know more about a specific part of the kata or NaturalSpec feel free to contact me.

Tags: , , , , , , ,

## Tuesday, 13. April 2010

### “FAKE – F# Make” and NaturalSpec released

Filed under: F#,FAKE - F# Make,Visual Studio — Steffen Forkmann at 8:06 Uhr

Yesterday Microsoft released the RTM versions of Visual Studio 2010, .NET Framework 4.0 and F# 2.0.0.0 and so it is time to announce the first official releases of ├óŌé¼┼ōFake ├óŌé¼ŌĆ£ F# Make├óŌé¼┬Ø and NaturalSpec. Both projects are now compatible with Visual Studio 2010 RC and RTM and the corresponding F# versions.

##### Fake ├óŌé¼ŌĆ£ F# Make version 1.0.0

"FAKE – F# Make" is a build automation system, which is intended to provide a much better tooling support than XML-based build languages like MSBuild or NAnt. Due to its integration in F#, all benefits of the .NET Framework and functional programming can be used, including the extensive class library, powerful debuggers and integrated development environments like Visual Studio 2008, Visual Studio 2010 or SharpDevelop, which provide syntax highlighting and code completion.

Like F# itself the new build language was designed to be succinct, typed, declarative, extensible and easy to use.

##### NaturalSpec version 1.0.0

NaturalSpec is a UnitTest framework based on NUnit and completely written in F# – but you don’t have to learn F# to use it. The idea is that you can write your spec mostly in a natural language like in the following sample:

[<Scenario>]

let “When removing an element from a list it should not contain the element“() =

Given [1;2;3;4;5]                 // "Arrange" test context

|> When removing 3              // "Act"

|> It shouldn’t contain 3       // "Assert"

|> It should contain 4          // another assertion

|> It should have (Length 4)    // Assertion for length

|> It shouldn’t have Duplicates // it contains duplicates ?

|> Verify                       // Verify scenario

If you have any questions about the projects feel free to contact me.

Tags: , , ,

## Sunday, 8. November 2009

### "Getting started" with NaturalSpec – (Updated 08.11.2009)

Filed under: .NET,F#,NaturalSpec — Steffen Forkmann at 10:48 Uhr

In my last article (Introducing NaturalSpec ├óŌé¼ŌĆ£ A Domain-specific language (DSL) for testing) I used NaturalSpec in two small samples. This time I will show how we can set up a NaturalSpec environment to write our first automatically testable scenarios.

##### 1. Choosing an IDE

The first step is to choose an integrated development environment for NaturalSpec. At the current project status you should be able to use NaturalSpec with Visual Studio 2008, Visual Studio 2010 beta 2, the freely available Visual Studio 2008 Shell or the free IDE SharpDevelop 3.0.

##### 2. Installing the testing framework

As NaturalSpec uses NUnit as the underlying testing framework we have to install NUnit 2.5. I also recommend installing TestDriven.Net in order to get a Unit Test runner within Visual Studio.

##### 3. Installing F#

NaturalSpec is completely written in F# and all specs will also be written in F#. This doesn├óŌé¼Ōäót imply you have to learn programming in F# but we need the F# compiler to get things working. You can download the F# October 2009 CTP from the Microsoft F# Developer Center.

##### 5. Creating a spec

This part is written for using Visual Studio 2008. If you use SharpDevelop or Visual Studio 2008 Shell this might differ in some detail.

Start Visual Studio 2008 and create a new F# class library. Rename Module1.fs in ListSpec.fs and delete script.fsx from the project: Create a folder ├óŌé¼┼ōLib├óŌé¼┬Ø and unzip the NaturalSpec libraries into it. Copy the following code into ListSpec.fs:

`module ListSpec`
```open NaturalSpec

[<Scenario>]
let When_removing_an_3_from_a_small_list_it_should_not_contain_3() =
Given [1;2;3;4;5]
|> When removing 3
|> It shouldn't contain 3
|> Verify```

If you have TestDriven.Net installed you can run your spec via right click in the solution explorer: If you don├óŌé¼Ōäót like the TestDriven.Net test runner you might want to use the NUnit GUI runner. The output should look like: In addition the test runner should produce a Spec output file with the name ├óŌé¼┼ōSpec.txt├óŌé¼┬Ø within the same folder.

##### Summary

In a minimal environment you need SharpDevelop, the F# compiler, NUnit and the NaturalSpec libraries for using NaturalSpec.

In the next post I will show how you can use NaturalSpec to create a spec for C# projects.

Tags: , , , , ,

## Sunday, 1. March 2009

### Testing Quicksort with NaturalSpec

Filed under: F#,NaturalSpec — Steffen Forkmann at 11:42 Uhr

In my last article I showed two ways to use parameterized scenarios in NaturalSpec. This time I will show how we can combine both to test a small Quicksort function.

First of all we define a scenario for sorting:

```/// predefined sorting scenario
let sortingScenario f list =
Given list
|> When sorting_with f
|> It should be sorted
|> It should contain_all_elements_from list
|> It should contain_no_other_elements_than list```
```/// predefined Quicksort scenario
let quicksortScenario list = sortingScenario QuickSort list```

Now we define some concrete test cases:

```[<Scenario>]
let When_sorting_empty_list() =
quicksortScenario []
|> Verify

[<Scenario>]
let When_sorting_small_list() =
quicksortScenario [2;1;8;15;5;22]
|> Verify

[<ScenarioTemplate(100)>]
[<ScenarioTemplate(1000)>]
[<ScenarioTemplate(2500)>]
let When_sorting_ordered_list n =
quicksortScenario [1..n]
|> Verify

[<ScenarioTemplate(100)>]
[<ScenarioTemplate(1000)>]
[<ScenarioTemplate(2500)>]
let When_sorting_random_list n =
quicksortScenario (list_of_random_ints n)
|> Verify  ```

After we defined our spec the task is now to implement the sorting function. I am using a very short (and very na├ā┬»ve) Quicksort implementation in F#:

```/// naive implementation of QuickSort - don't use it
let rec quicksort = function
| [] -> []
| pivot :: rest ->
let small,big = List.partition ((>) pivot) rest
quicksort small @ [pivot] @ quicksort big

let QuickSort x =
printMethod ""
quicksort x   ```

If we run the scenario, we get the following output (I shortened a bit):

Scenario: When sorting empty list

– Given []
– When sorting with QuickSort
=> It should be sorted
=> It should contain all elements from []
=> It should contain no other elements than []
==> Result is: []
==> OK
==> Time: 0.0355s

Scenario: When sorting small list

– Given [2; 1; 8; 15; 5; 22]
– When sorting with QuickSort
=> It should be sorted
=> It should contain all elements from [2; 1; 8; 15; 5; 22]
=> It should contain no other elements than [2; 1; 8; 15; 5; 22]
==> Result is: [1; 2; 5; 8; 15; 22]
==> OK
==> Time: 0.0065s

Scenario: When sorting ordered list

[├óŌé¼┬”]  100 elements
==> OK
==> Time: 0.0939s

Scenario: When sorting ordered list

[├óŌé¼┬”]  1000 elements
==> OK
==> Time: 0.7130s

Scenario: When sorting ordered list

[├óŌé¼┬”]  2500 elements
==> OK
==> Time: 3.0631s

Scenario: When sorting random list

[├óŌé¼┬”]  100 elements
==> OK
==> Time: 0.0485s

Scenario: When sorting random list

[├óŌé¼┬”]  1000 elements
==> OK
==> Time: 0.1878s

Scenario: When sorting random list

[├óŌé¼┬”]  1000 elements
==> OK
==> Time: 0.8713s

As you can see the function is much faster if we sort a random list. This is because of the na├ā┬»ve choice of the pivot element.

I don├óŌé¼Ōäót want to give better implementations here (use LINQ or PLINQ). I just wanted to show how we can easily verify a test function with NaturalSpec.

Tags: , ,

## Saturday, 28. February 2009

### Parameterized Scenarios with NaturalSpec

Filed under: F#,NaturalSpec — Steffen Forkmann at 16:46 Uhr

I wrote a lot about NaturalSpec in my last articles. This time I will show how we can use parameterized scenarios.

##### 1. Using predefined scenarios

By writing predefined parameterized scenarios we can easily create a scenario suite with lots of different test cases:

```// predefined scenario
let factorialScenario x result =
Given x
|> When calculating factorial
|> It should equal result

[<Scenario>]
let When_calculation_factorial_of_1() =
factorialScenario 1 1
|> Verify

[<Scenario>]
let When_calculation_factorial_of_10() =
factorialScenario 10 3628800
|> Verify```

If we run these scenarios with NUnit we will get the following output:

Scenario: When calculation factorial of 1

– Given 1

– When calculating factorial

=> It should equal 1

==> OK

==> Time: 0.0093s

Scenario: When calculation factorial of 10

– Given 10

– When calculating factorial

=> It should equal 3628800

==> OK

==> Time: 0.0018s

##### 2. Using the ScenarioTemplate attribute

The second and shorter option is to use the ScenarioTemplate attribute, which is inherited from NUnit├óŌé¼Ōäós new TestCase attribute:

```// with ScenarioTemplate Attribute
[<ScenarioTemplate(1, 1)>]
[<ScenarioTemplate(2, 2)>]
[<ScenarioTemplate(5, 120)>]
[<ScenarioTemplate(10, 3628800)>]
let When_calculating_fac_(x,result) =
Given x
|> When calculating factorial
|> It should equal result
|> Verify```

This code will create 4 different scenarios, which NUnit will display and report separately: ##### 3. Using ScenarioSource

The third option is to use the ScenarioSource attribute. Here we define a function which generates TestData:

```/// with a scenario source
let MyTestCases =
TestWith 12 3 4
|> And 12 4 3
|> And 12 6 2
|> And 1200 40 30
|> And 0 0 0 |> ShouldFailWith (typeof<System.DivideByZeroException>)```

And then we have to tell NaturalSpec which TestData a scenario should use:

```[<Scenario>]
[<ScenarioSource "MyTestCases">]
let When_dividing a b result =
Given a
|> When dividing_by b
|> It should equal result
|> Verify```
` `
##### Summary

Sometime it makes sense to test a scenario with a bunch of different parameters. We can use the ScenarioTemplate attribute to easily parameterize our scenarios. If we want more flexibility we can use predefined scenarios with custom parameters or the ScenarioSource attribute.

Tags: , , , ,

## Wednesday, 25. February 2009

### Mocking objects with NaturalSpec

Filed under: F#,NaturalSpec — Steffen Forkmann at 16:56 Uhr

In my last articles I gave an introduction in NaturalSpec, showed how to get started and demonstrated how we can use NaturalSpec to write automatically testable scenarios for C# projects. This time I will use the same ├óŌé¼┼ōCar-Dealer├óŌé¼┬Ø-sample to show how we can mock objects in NaturalSpec.

Mocking objects is an important technique in Test-driven development (TDD) and allows us to simulate complex behavior.

├óŌé¼┼ōIf an object has any of the following characteristics, it may be useful to use a mock object in its place:

• supplies non-deterministic results (e.g. the current time or the current temperature);
• has states that are difficult to create or reproduce (e.g. a network error);
• is slow (e.g. a complete database, which would have to be initialized before the test);
• does not yet exist or may change behavior;
• would have to include information and methods exclusively for testing purposes (and not for its actual task).├óŌé¼┬Ø

Wikipedia

In our sample we want to mock the Dealer.SellCar() functionality. The first step is to create an C#-Interface for the Dealer:

```namespace CarSellingLib
{
public interface IDealer
{
Car SellCar(int amount);
}
}```

NaturalSpec is using Rhino.Mocks as the underlying mocking framework, so we have to create a reference to Rhino.Mocks.dll in our spec library.

Now we can modify our spec to:

```// 1. open module
module CarSpec```
```// 2. open NaturalSpec-Namespace
open NaturalSpec

// 3. open project namespace
open CarSellingLib

// define reusable values
let DreamCar = new Car(CarType.BMW, 200)
let LameCar = new Car(CarType.Fiat, 45)

// 4. define a mock object and give it a name
let Bert = mock<IDealer> "Bert"

// 5. create a method in BDD-style
let selling_a_car_for amount (dealer:IDealer) =
printMethod amount
dealer.SellCar amount

// 6. create a scenario
[<Scenario>]
let When_selling_a_car_for_30000_it_should_equal_the_DreamCar_mocked() =
As Bert
|> Mock Bert.SellCar 30000 DreamCar  // 7. register mocked call
|> When selling_a_car_for 30000
|> It should equal DreamCar
|> It shouldn't equal LameCar
|> Verify```

As you can see we changed part 4 (in order to get a mocked IDealer instead of the concrete Dealer). In part 7 we register our mocked behavior. We want that whenever Bert.SellCar is called with parameter 30000 the DreamCar should be returned.

The Verify-function checks if the mocked function has been called. If not the scenario will fail.

If we verify our spec with a NUnit runner we get the following output:

Scenario: When selling a car for 30000 it should equal the DreamCar mocked

– As Bert

– With Mocking

– When selling a car for 30000

=> It should equal BMW (200 HP)

=> It should not equal Fiat (45 HP)

==> OK

Tags: , , ,

## Monday, 23. February 2009

### Using NaturalSpec to create a spec for C# projects (Updated 08.11.2009)

Filed under: F#,NaturalSpec — Steffen Forkmann at 18:07 Uhr

In my last two articles I gave an introduction in NaturalSpec and showed how to get started. This time I will show how we can use NaturalSpec to write automatically testable scenarios for C# projects.

Like the TDD principle ├óŌé¼┼ōWrite the tests first├óŌé¼┬Ø we should write our spec first and use the ├óŌé¼┼ōRed-Green-Refactor├óŌé¼┬Ø method.

##### "Red" ├óŌé¼ŌĆ£ Create a spec scenario that fails

At first I created a F# class library project called ├óŌé¼┼ōSpec.CarSelling├óŌé¼┬Ø and added project references to NaturalSpec.dll and nunit.framework.dll (see ├óŌé¼┼ōGetting started├óŌé¼┬Ø for further explanations).

Now I can write my first scenario:

```// 1. define the module
module CarSpec```
```// 2. open the NaturalSpec namespace
open NaturalSpec

// 3. open project namespace
open CarSellingLib

// 4. define a test context
let Bert = new Dealer("Bert")

// 5. create a method in BDD-style
let selling_a_car_for amount (dealer:Dealer) =
printMethod amount
dealer.SellCar amount

// 6. create a scenario
[<Scenario>]
let When_selling_a_car_for_30000_it_should_equal_my_DreamCar() =
As Bert
|> When selling_a_car_for 30000
|> It should equal (new Car(CarType.BMW, 200))
|> Verify```

At this stage the scenario is ready but doesn├óŌé¼Ōäót compile. This means we are ready with the "Red"-stage.

##### "Green" ├óŌé¼ŌĆ£ Make the test the pass

In order to get the test green we have to create a C# class library called CarSellingLib and define the enum CarType and the classes Dealer and Car. Sticking to the YAGNI-principle we implement only the minimum to get the spec green (and ToString()-members for the output functionality).

```namespace CarSellingLib
{
public enum CarType
{
BMW
}
}```

```namespace CarSellingLib
{
public class Car
{
public Car(CarType type, int horsePower)
{
Type = type;
HorsePower = horsePower;
}

public CarType Type { get; set; }
public int HorsePower { get; set; }

public override string ToString()
{
return string.Format("{0} ({1} HP)", Type, HorsePower);
}

public override bool Equals(object obj)
{
var y = obj as Car;
if(y == null) return false;
return Type == y.Type && HorsePower == y.HorsePower;
}
}
}```
```using System;

namespace CarSellingLib
{
public class Dealer
{
public Dealer(string name)
{
Name = name;
}

public string Name { get; set; }

public Car SellCar(int amount)
{
return new Car(CarType.BMW, 200);
}

public override string ToString()
{
return Name;
}
}
}```

When we add a project reference to our spec-project the UnitTests should pass and we have completed the "Green" step. (See "Getting started" if you don├óŌé¼Ōäót know how to run the spec.) Now we can add some more scenarios to our spec:

```// 1. define the module
module CarSpec```
```// 2. open NaturalSpec-Namespace
open NaturalSpec

// 3. open project namespace
open CarSellingLib

// 4. define a test context
let Bert = new Dealer("Bert")

// define reusable values
let DreamCar = new Car(CarType.BMW, 200)
let LameCar = new Car(CarType.Fiat, 45)

// 5. create a method in BDD-style
let selling_a_car_for amount (dealer:Dealer) =
printMethod amount
dealer.SellCar amount

// 6. create a scenario
[<Scenario>]
let When_selling_a_car_for_30000_it_should_equal_the_DreamCar() =
As Bert
|> When selling_a_car_for 30000
|> It should equal DreamCar
|> It shouldn't equal LameCar
|> Verify

[<Scenario>]
let When_selling_a_car_for_19000_it_should_equal_the_LameCar() =
As Bert
|> When selling_a_car_for 19000
|> It should equal LameCar
|> It shouldn't equal DreamCar
|> Verify```

```// create a scenario that expects an error
[<Scenario>]
[<Fails_with "Need more money">]
let When_selling_a_car_for_1000_it_should_fail_with_Need_More_Money() =
As Bert
|> When selling_a_car_for 1000
|> Verify```

Now we are in the ├óŌé¼┼ōRed├óŌé¼┬Ø-Phase again.

##### "Refactor" – rearrange your code to eliminate duplication and follow patterns

After making the spec "Green" and doing some refactoring the project code could look like this:

```namespace CarSellingLib
{
public enum CarType
{
Fiat,
BMW
}
}```

```namespace CarSellingLib
{
public class Car
{
public Car(CarType type, int horsePower)
{
Type = type;
HorsePower = horsePower;
}

public CarType Type { get; set; }
public int HorsePower { get; set; }

# region ToString, Equals

public override string ToString()
{
return string.Format("{0} ({1} HP)", Type, HorsePower);
}

public override bool Equals(object obj)
{
var y = obj as Car;
if(y == null) return false;
return Type == y.Type && HorsePower == y.HorsePower;
}

#endregion
}
}```

```using System;

namespace CarSellingLib
{
public class Dealer
{
public Dealer(string name)
{
Name = name;
}

public string Name { get; set; }

public Car SellCar(int amount)
{
if (amount > 20000)
return new Car(CarType.BMW, 200);

if (amount > 3000)
return new Car(CarType.Fiat, 45);

throw new Exception("Need more money");
}

public override string ToString()
{
return Name;
}
}
}```

The spec output should look like the following:

Scenario: When selling a car for 1000 it should fail with Need More Money

– Should fail…
– As Bert
– When selling a car for 1000

Scenario: When selling a car for 19000 it should equal the LameCar

– As Bert
– When selling a car for 19000
=> It should equal Fiat (45 HP)
=> It should not equal BMW (200 HP)
==> OK

Scenario: When selling a car for 30000 it should equal my DreamCar

– As Bert
– When selling a car for 30000
=> It should equal BMW (200 HP)
==> OK

Scenario: When selling a car for 30000 it should equal the DreamCar

– As Bert
– When selling a car for 30000
=> It should equal BMW (200 HP)
=> It should not equal Fiat (45 HP)
>==> OK

4 passed, 0 failed, 0 skipped, took 1,81 seconds (NUnit 2.5).

##### Summary

I showed how we can use NaturalSpec for the Red-Green-Refactor process of C# projects and how easy it is to get a spec in natural language.

Tags: , , , , ,

### Introducing NaturalSpec – A Domain-specific language (DSL) for testing – Part I

Filed under: C#,F#,NaturalSpec,Tools — Steffen Forkmann at 11:31 Uhr

Test-Driven development (TDD) is a well known software development technique and follows the mantra ├óŌé¼┼ōRed-Green-Refactor├óŌé¼┬Ø. Behavior-Driven Development (BDD) is a response to TDD and introduces the idea of using natural language to express the Unit Test scenarios.

There are a lot of popular testing frameworks around which can be used for BDD including xUnit.net ,NUnit, StoryQ, MSpec, NSpec and NBehave. Most of them can be used with fluent interfaces and therefore provides a good readability of the sources. Some of them even provide the possibility to generate a spec in natural language out of passed Unit tests.

##### What is a spec?

├óŌé¼┼ōA specification is an explicit set of requirements to be satisfied by a material, product, or service.├óŌé¼┬Ø

American Society for Testing and Materials (ASTM) definition

A spec is an important document for the communication process ├óŌé¼ŌĆ£ it enables domain experts to communicate with developers. But how can you verify the compliance with the spec? The answer is: you have to write unit tests. Even with the mentioned frameworks there is a lot of work to do in order to translate a spec scenario into a Unit Test.

Question 7 in the famous Joel Test is ├óŌé¼┼ōDo you have a spec?├óŌé¼┬Ø.

The idea of NaturalSpec is to give domain experts the possibility to express their scenarios directly in compilable Unit Test scenarios by using a Domain-specific language (DSL) for Unit Tests. NaturalSpec is completely written in F# ├óŌé¼ŌĆ£ but you don├óŌé¼Ōäót have to learn F# to use it. You don├óŌé¼Ōäót even have to learn programming at all.

##### Example 1 ├óŌé¼ŌĆ£ Specifying a list

Let├óŌé¼Ōäós consider a small example. If we want to test a new List implementation a spec could look like this:

```[<Scenario>]
let When_removing_an_3_from_a_small_list_it_should_not_contain_3() =
Given [1;2;3;4;5]              // ├óŌé¼┼ōArrange├óŌé¼┬Ø test context
|> When removing 3           // ├óŌé¼┼ōAct├óŌé¼┬Ø
|> It shouldn't contain 3    // ├óŌé¼┼ōAssert├óŌé¼┬Ø
|> It should contain 4       // another assertion
|> Verify                    // Verify scenario```

I used BDD style here and expressed my scenario in a quite natural language. As the comments are indicating the scenario is following the Arrange Act Assert (├óŌé¼┼ōAAA├óŌé¼┬Ø) pattern.

With the Keyword ├óŌé¼┼ōGiven├óŌé¼┬Ø I can create a test context (the objects I want to test). In this sample I created a list with 5 elements. With the keyword ├óŌé¼┼ōWhen├óŌé¼┬Ø I call a function which does something with my test context. In this case I want to remove the value 3. In the Assert section (keywords ├óŌé¼┼ōIt should├óŌé¼┬Ø or ├óŌé¼┼ōIt shouldn├óŌé¼Ōäót├óŌé¼┬Ø) I can give some observations, which should hold for my manipulated test context.

When I run this scenario via a NUnit runner (i am using TestDriven.Net) I get the following output:

Scenario: When removing an 3 from a small list it should not contain 3

– Given [1; 2; 3; 4; 5]
– When removing 3
=> It should not contain 3
=> It should contain 4
==> OK

##### Example 2 ├óŌé¼ŌĆ£ Specifying a factorial function

If you implement factorial function the spec could look like this:

```[<Scenario>]
let When_calculating_fac_5_it_should_equal_120() =
Given 5
|> When calculating factorial
|> It should equal 120
|> Verify

[<Scenario>]
let When_calculating_fac_1_it_should_equal_1() =
Given 1
|> When calculating factorial
|> It should equal 1
|> Verify

[<Scenario>]
let When_calculating_fac_0_it_should_equal_0() =
Given 0
|> When calculating factorial
|> It should equal 1
|> Verify```

And the output of NaturalSpec would look like this:

Scenario: When calculating fac 0 it should equal 0

– Given 0
– When calculating factorial
=> It should equal 1
==> OK

Scenario: When calculating fac 1 it should equal 1

– Given 1
– When calculating factorial
=> It should equal 1
==> OK

Scenario: When calculating fac 5 it should equal 120

– Given 5
– When calculating factorial
=> It should equal 120
==> OK

##### Getting started

Of course you can use NaturalSpec to specify C# objects. I see my post "Using NaturalSpec to create a spec for C# projects" for a small sample.