Navigate / search

Groundhog Dev

Back at NDC in June, one of the talks I enjoyed most was Fred George’s “Microservice Architecture”. It focused something I already believed in (deploying software in small, chunks that are as isolated from each other as possible).

But Mr. George goes way further than that. He believes in disposable software. Pieces of functionality that are small enough that they can be thrown away and rewritten. He talks of software having a lifespan of weeks, and not months or years.

He believes in well-defined interfaces between these small “services”, but there are few rules for what goes on inside. If a developer wants to fix a bug in an existing service he can. If he wants to throw it away and re-write it, he can. If he wants to use a completely different programming language, he can.

In the course of explaining the architecture, Mr. George said something that knocked me back a bit. He said that his architecture reduces the need for unit tests. TDD didn’t seem to be part of his approach.

This came hot on the heels of Dan North’s “Decisions Decisions” talk, where he pointed out that there are no sacred cows, everything is a trade-off, even TDD. Two talks into NDC 2012, and I’m being talked out of using Automated Tests. My kind of conference.

So, this week I tried it. I tried writing code, with no automated tests. That part isn’t new, I do that all the time. What was new was I wrote the code with the intention to throw it away and start again if the need arose.

If I felt the design had gotten away from me, I’d throw it away. If I tried to make a change and the code was working against me, I’d throw it away.

It’s Groundhog Dev. Sonny and Cher sing “I got you babe”, the Visual Studio editor is blank and you start again, with a chance to do things a little differently, armed with the knowledge from the groundhog Dev sessions that have gone before.

So what happened?

Iteration 1
I just build the feature. No TDD, no BDD, no automated tests of any kind. A little up front design, and then on with the show.

The End Result?
Not so good actually. At a certain point I discovered that I needed to get the Absolute value of a number, and there was no clean place to get it. If I got it too soon, I lose the sign, which I need later. If I get it too late an earlier calculation is wrong.

When this happens it’s the code speaking to you. Your design sucks. Start over.

Iteration 2
Armed with what I’d learned from Iteration 1, I scrapped it all and started again. Still no automated tests, a bit more design up front to take account of some things I hadn’t realised first time through.

The End Result?
Better. The problem with the sign vanished. I’ve messed a little with F# recently, and there was a definite “functional” feel to what I ended up with. But, it felt a little over-engineered in places.

It worked though, which is kinda the point.

Iteration 3
OK, there didn’t need to be an iteration 3. But something about iteration 2 bugged me. Those over-engineered bits. Surely the last thing that disposable software should be is over-engineered.

I have also been working with FitNesse more and more, and had tried and failed in the past to find a place for it. But this little project seemed tailor-made for it. It looked like it could be a perfect example of how FitNesse could work for us.

I started again. But this time there would be tests. Only FitNesse end-to-end tests, no Unit Tests.

The End Result?
To be blunt, astonishing. Now, there is a warning that this was my third time in a week rewriting the same piece of functionality, so any improvements I report in iteration 3 will be quickly dismissed as just knowing the problem better, but I don’t think that’s it.

Once I had figured out the way I could test the feature (which is by far the hardest part of using FitNesse, or any testing Framework) the process of writing the code flowed beautifully.

Even though I wasn’t TDD’ing at the Unit Test level, I still found I was working in small increments, I had less long hacking sessions. Less compile errors to work through.

The resulting design was much cleaner than either of my first two attempts. It was also more decoupled from surrounding code, which is one of the goals I had been shooting for.

The amount of code dropped substantially, all the over-engineered bits simply vanished. Five classes were effectively folded into one, with no loss of cohesion.

I suspect that Fred George’s approach to developing software is not something you can just ‘Do’, in the way I tried to. He talks about the well-defined interface between services. It’s clear there are techniques, standards and patterns that he follows that would need to be learned to be successful.

For me, the revelation was the value of tests. Even, or perhaps especially end-to-end tests. Developing a feature guided by end-to-end tests, I found myself energised in a way that I wasn’t when I was just coding to a design.

This may go against what Mr. George was trying to get across. I’m not for a second saying that what he proposes is wrong, or wouldn’t work. I’m sure it would and I’d love to experience it, someday.

For today though, for me, for the skill set I have, and for my temperament, tests are what work.

If you can find the time, and the right small discrete piece of functionality, I would urge you to try your own experiment. You don’t have to adopt the same approaches I did, but try something different.

Having developed the third iteration of this little project I tried a parallel run of iterations 2 and 3, just to make sure all was working as expected. They weren’t. I discovered one or two bugs in iteration two. For what it’s worth, it wasn’t the tests that I wrote for iteration 3 that eliminated those bugs directly. It was the significantly simpler code.

Why I’d skip the NDC Preconference workshops

Earlier today I tweeted that if I was attending NDC Oslo again (and I hope I will) I might consider skipping the Pre-Conference Workshops.

Understandably a comment like that, made within the constraints of 140 characters can raise a few eyebrows, so here’s a more considered review of what I got out of the workshops, and why I might spend the time differently in future.

I want to say at the outset that it may sound like criticism of the workshop hosts to say that I’d skip them in future, but that isn’t really the case. I got valuable information from both workshops, my only question would be whether I could have gotten that information in another way, and used those two days more productively.

Let me give a little run down of my experience and see if I start making sense any time soon.

In the case of the RavenDB workshop I was vaguely aware of the NoSQL concept, but I had no previous exposure to RavenDB, I now feel like I have a good handle on it, and I definitely got something out of that day.

My only real quibble with it would be the decision to have attendees create an ASP.Net/MVC project to demonstrate Raven DB. I just don’t get the point of that. The MVC project brought nothing to the table that couldn’t be demonstrated with a Console Application. What it did do was make things difficult for anyone who isn’t familiar with ASP/MVC.

I had spent a few hours looking at ASP/MVC some months back, so it wasn’t completely alien, but it was just about alien. Instead of focusing my brain on RavenDB I found myself googling how to have a controller return JSON directly, rather than use a View.

It’s a small thing, but it’s unnecessary. All the project did was demonstrate creating RavenDB Docs, Query them, create and use indexes ets. All very basic, and a Console App would have allowed everybody to focus purely on Raven.

My colleague went a step further and spurned the ASP/MVC project in favour of simply using LinqPad.

Apart from that one issue, I found the day useful, we’ll be presenting a demo of RavenDB to our colleagues who couldn’t attend NDC, and we may even find a project to us it on at some point in the future.

The FitNess/Acceptance Testing workship was a little different. I’ve been playing with FitNesse for a while and we’ve been working on finding a way to use it on our projects. We had hit a few roadblocks in our work with FitNesse, so I was really looking forward to picking Uncle Bob’s brain on some of those.

All the questions were answered and then some. I did come away from the workshop with knowledge about FitNesse that I had lacked previously. Despite this, I view that workshop as a huge missed opportunity.

The format of the workshop is:
Uncle Bob poses a programming challenge, (in this case the game Hunt The Wumpus).
He presents an introduction to FitNesse, talks a little about it’s history and then asks you to build the Hunt The Wumpus game using FitNesse tests.

For most of the day we coded in silence while Uncle Bob tapped away on his laptop in silence. He was always available to answer any question, and his answers, particularly on specific FitNesse issues were clear and to the point, (at least his answers to me were).

It did strike me however that I was spending 8 hours sitting 10 feet from Uncle Bob, but we weren’t having the kind of free flowing discussion, or even one-way lecture that I had hoped for. It seemed absurd to spend the day hacking on a project that I could just as easily hack on at home.

I don’t know how everybody else fared with the assignment, and I must admit I ditched it after lunch and instead opened up some of my FitNesse code from home. I had come with some specific questions and issues and I wanted to go through them, so that’s what I did.

I would have liked the workshop to be more about the nitty gritty of using FitNesse, more discussion of the various types of tables and where they are or are not appropriate. More tales from the coldface of actually using FitNesse in the wild. More war stories about things that have worked and things that haven’t. Discussion of the problems Refactoring FitNesse. We did have a talk about FitNesse and Version Control, but only because someone thought to ask.

He did show some BDD-like use of Scenario Libraries which was really interesting and that’s the stuff I wanted more of.

Towards the end of the workshop one of the attendees expressed a little disappointment with the content of the workshop. Uncle Bob did say that ordinarily it would be a 2 day workshop. My sense was that to get it down to one day the wrong half of the content might have been cut.

If I were to be specifically critical I would point out the following claim from the blurb of the workshop:

“step by step, test case by test case we’ll use TDD, Refactoring, and Clean Code practices to get this application working”

This may be true in the two day version of the workshop, I don’t know, but in the workshop I attended we were pretty much left to our own devices to code the app any way we wanted.

As it happens, a worked example with Uncle Bob doing TDD, Refactoring, Clean Code etc. would have been very interesting.

I genuinely think that if I were attending NDC Oslo again, my time might be better served tracking down a few fellow coders who’d be interested in spending the two days prior to the conference hacking, debating and exchanging ideas.

I would consider trying to book a small conference room in a hotel and getting 5-10 people in and seeing what we can learn from each other.

So, there you have it, I hope that clarifies my earlier comments.

Fire At Will.

FitNesse with .Net – Decision Tables

This entry is part 3 of 5 in the series FitNesse

In the last post, we created a very simple FitNesse test to show that everything is set up correctly, and we can test .Net code.

That example used a Decision Table which is not only one of the easiest tables to use, but also a surprisingly versatile and useful table. In this post we’ll look at the Decision Table in more detail.

Decisions Decisions
Decision tables consist of columns that are either inputs to a test or expected results from the test. Each row in the table represents a separate test case. In the last post we tested a simple calculation using a simple Calculator C# project. Let’s look at the Markup for that Table, line by line.

Line 1 defines the name of the table, and by convention this also tells FitNesse the name of the Class it should try to use when executing the test. In this case FitNesse will search for a class called Calculation.

Line 2 defines the parameters of the test, but the input values we’ll sent to the test, and the output values we get back. In this case A, B and Op are all input parameters. Result is an output value as indicated by the question mark ‘?’.

Lines 3 and consist of the values to be used with the Test. We supply 1, 2 and + and we state that we expect the value 3 to be the result of adding 1 and 2. We have a separate test case which tests that adding 1 and -1 results in 0.

|Calculation   |
|1|2|+ |3      |
|1|1|- |0      |

Decision Table Fixtures
As mentioned above the name of the Table dictates the name of the class that FitNesse will attempt to execute the test.

It may be that a table name and the particular input and output columns are ideal for describing features of the system, but are not good names for objects in our domain model.

This is where Fixtures come in. Generally speaking we don’t want to write FitNesse tests that directly access the domain model. Apart from the fact that good names for tests may not make good interfaces for objects, there is also a brittleness from hooking up directly to a Domain Model that could change.

Test Fixtures provide a level of abstraction between FitNesse and our System Under Test. Fixtures are usually simple pass through objects that invoke the expected behaviour and return apropriate results.

We declare the inputs as public fields. There’s no benefit in declaring properties and private fields in a fixture. We want the simplest possible implementation that allows us to get values in and out.

public class DoSimpleMaths
    public decimal A;
    public decimal B;
    public string Op;

    public decimal Result()
        if (Op == "+")
            return Calculator.Add(A, B);

        if (Op == "-")
            return Calculator.Subtract(A, B);

        if (Op == "*")
            return Calculator.Multiply(A, B);

        if (Op == "/")
            return Calculator.Divide(A, B);

        throw new NotImplementedException(string.Format("'{0}' is not an implemented Operator", Op));

The following fixture implements the Result output as a function. If your Decision Table includes multiple outputs you can implement each as a separate function for each.

public class DoDivisionWithRemainder
    public int A;
    public int B;

    public int Result()
        return A / B;

    public int Remainder()
        return A % B;

If the work of the fixture can be implemented in a single method, you could consider the following alternative approach. Use public fields for all inputs and outputs, then use a method called Execute to populate all of the outputs.

FitNesse will run the ‘Execute’ method before evaluating the outputs.

public class DoDivisionWithRemainder
    public int A;
    public int B;
    public int Result;
    public int Remainder;
    public void Execute()
        Result = A / B;
        Remainder = A % B;

The following FitNesse Decision Table will work with either of the previous two Test Fixtures.

!|Do Division With Remainder|
|A  |B |Result? |Remainder? |
|13 |5 |2       |3          |

Beyond the Basics
We can do some interesting things beyond the basic decision tables shown above. For example if we have inputs that will be the same for each row in the table, we can define it once in the header.

!|AddAFixedPercentage        |10     |
|Principal                   |Result?|
|0                           |0.0    |
|10                          |11.0   |
|100                         |110.0  |

In the above example, the value 10 is passed into the constructor of the fixture. It can then be used for each row, without needing a column for it in the table.

public class AddAFixedPercentage
    public decimal principal;
    private decimal _percentage;

    public AddAFixedPercentage(decimal <span class="hiddenGrammarError" pre="">percentage)
        _percentage</span> = percentage;

    public decimal result()
        return Calculator.AddPercentage(principal, _percentage);

If you want to pass more than one parameter to the Fixture you can do that. Just add them to the first row in the table. Make sure that the constructor has the correct number of parameters of the correct types to accept the values in the table.

!|FixtureName  |10 |ABC |3.14 |

When testing our expected results against the actual results, we also have options. We don’t need to find an exact match in order to pass a test. Sometimes an approximate match, or a range of values may be sufficient. Let’s remind ourselves of the markup for an exact match.

!|Do Simple Maths  |
|A  |B  |Op|Result?|
|6  |2  |/ |3      |

If we use the ~= operator we can match on approximately equal values.

|22|7|/ |~=3.14      |

22/7 is the famous approximation of PI, but in reality it’s not all that close an approximation. In fact it all goes wrong if you look beyond 2 decimal places. The Test above will pass because at two decimal places, 22/7 matches 3.14.

We can also check that a value is Grater Than another.

|10|1|+ |>10      |

Or that a value falls within a given range.

|5|3|* |14<_<16   |

When Decision Tables Work Best
As mentioned above, Decision Tables are very useful when we have a set of clearly defined Inputs and Outputs. It may seem that most problems can be reduced to this sort of scenario, and that’s probably true, however we’ll see other options in subsequent posts for other types of scenarios.

Aha! Unit Tests – DDDBelfast

Sample Code

On Saturday I spoke at DDDBelfast. My Session was on Unit Testing. After the Test Driven Development session in Bristol, it occured to me that a more fundamental problem was Unit Testing itself. Whether the Tests are Written before or after the code is a non-issue if developers aren’t writing automated Unit Tests at all.

Here are the slides for the session.

The sample Code includes the Wizard project which includes a suite of Unit Tests, you’ll need to install MOQ and NUnit to run all the tests.

Also included are the three examples of injecting mocks, and the example of how traditional NTier code can violate the Single Responsibility Principal, and how to avoid that problem

Any questions about any of this, feel free to get in touch or leave a comment.

FitNesse with .Net: Hello World

This entry is part 4 of 5 in the series FitNesse

Sample Code

In the last post we installed FitNesse and FitSharp, but we didn’t actually do anything with them. In this post we’ll rectify that with what is essentially the Hello World of FitNesse tests.

Test Fixtures
The point of FitNesse is that you use it to write executable specifications. There are two ways you can do this. You can have the FitNesse tests work directly against your code, or you can build Fixture Classes which serve as an adaptor between FitNesse and the System Under Test (SUT).

There is no right or wrong approach to this, as always there are pros and cons to both. On one hand you could argue that good FitNesse tests should reflect the language of the domain and so there should be no need to have an adaptor between the two.

On the other hand, FitNesse/Slim has certain peculiarities in how it communicates with the system under test, allowing those peculiarities to influence your production code is probably not a good idea. Also, if you refactor your design you won’t always want to update wiki pages for every test case affected by that change. Sometimes you will, but a buffer isn’t necessarily a bad thing.

For the purposes of this post we’ll write tests that work directly with the domain model. In future posts we’ll use fixtures so you see both approaches in action.

Test First
Let’s make things a little more interesting by working through this example in a test first fashion. This means we’ll be creating the tests in FitNesse before we even look at writing any code in Visual Studio.

Get FitNesse running, and navigate to the main page. See the previous post in the series for help on doing this.

Click on the ‘Edit’ button and insert the text CalculatorDemo (all one word, upper case the C and D). I’ve put it at the top of the existing text, as follows:


!1 Welcome to [[FitNesse][FitNesse.FitNesse]]!
!3 ''The fully integrated stand-alone acceptance testing framework and wiki.''

# Here is a good place to add your first page (WikiWord). For example, MyTopLevelApplicationPage
To add your first "page", click the [[Edit][FrontPage?edit]] button and add a [[!-WikiWord-!][FitNesse.UserGuide.WikiWord]] to the page.

| '''To Learn More...'''|
| [[A One-Minute Description][FitNesse.UserGuide.OneMinuteDescription]]|''What is [[FitNesse][FitNesse.FitNesse]]? Start here.''|
| [[A Two-Minute Example][FitNesse.UserGuide.TwoMinuteExample]]|''A brief example. Read this one next.''|
| [[User Guide][FitNesse.UserGuide]]|''Answer the rest of your questions here.''|
| [[Acceptance Tests][FitNesse.SuiteAcceptanceTests]]|''FitNesse's suite of Acceptance Tests''|
| [[Release Notes][FitNesse.ReleaseNotes]]|''Find out about FitNesse's new features''|

!note Release ${FITNESSE_VERSION}

Click ‘Save’ and you should now see ‘CalculatorDemo[?]’ That question mark tells you that this is a link to a page that does not yet exist. FitNesse assumed it was a link to a page because of the casing. We’ll return to some of FitNesse’s ‘IntereSting’ rules about page names in a future post.

Click the question mark and FitNesse will automatically create the CalculatorDemo and begin editing it. Enter the following text

The system can perform basic arithmetic calculations

|Calculation   |
|1|2|+ |3      |
|1|1|- |0      |

Click the ‘Save’ button and you’ll be presented with your new page, containing your first test.

We’re a long way from a passing test at this point. In fact we’re a long way from a test that can even be run. Let’s sort out the various hurdles one by one.

The first problem is that there is no button to actually run the test. This is easily fixed. Hover over the ‘Tools’ buttons, select properties. On the resulting page change the page type to ‘Test’ and click [Save Properties].

You should now have a ‘Test’ button on your CalendarDemo FitNesse page. Click it and see what happens.

A big sea of yellow, which in a nutshell is telling you that it couldn’t find the code needed to run the test against. There are a few reasons for this. We haven’t told FitNesse how to call .Net code. We haven’t written any .Net code, and even if we had, we haven’t told FitNesse were to find it.

Let’s configure Slim so that FitNesse can talk to .Net.

Configure Slim
Look on the footer of the page in FitNesse. You should see a link to ‘root’. Click it and edit resulting page. Enter the following text.

!define TEST_SYSTEM {slim} 
!define COMMAND_PATTERN {%m -r fitSharp.Slim.Service.Runner,FitSharp\fitsharp.dll %p} 
!define TEST_RUNNER {FitSharp\Runner.exe} 

What we’re doing here is telling FitNesse to use Slim for running tests, and the commands to use to run them. the path to fitsharp.dll and Runner.exe should match the folder you placed fitsharp in when you downloaded it. This path is relative to the folder where you placed the FitNesse JAR file.

The System Under Test
Open up Visual Studio, create a C# Class Library called ‘Calculator’, add a class to the library called ‘Calculation’, Note that the title of the table we created in FitNesse. The table will map to this class. The Columns A, B, Op and Result need to map to properties of the Class. Here’s some code that will work.

namespace Calculator
    public class Calculation
        public double A { get; set; }
        public double B { get; set; }
        public string Op { get; set; }

        public double Result()
            return A + B;

When FitNess encounters a row in our table, it will set the A, B and Op properties, it will then run the Result method and check the value returned against the value in the table.

We’re not quite ready for that yet. Create a c:\DevTools\FitNesse\projects\Calculator folder. Build the solution, take the DLL it produces and put the dll in the new folder.

Hook FitNesse up to the System Under Test
This is the final step in the process. Go to the CalculatorDemo page and edit it. Add the following text at the top of the page.

!path projects\Calculator\Calculator.dll

|import     |
|Calculator |

The ‘path’ line points FitNesse at our dll. The ‘import’ table tells FitNesse which Namespace(s) it should look in to find the Class that handles the test table.

And, you’re done. Save these changes then click ‘Test’ and you should see the results.

The first row passes (turns green) because our code correctly Adds A and B. The second row fails because the Operator is ‘-‘ but the code only knows how to add.

In the next post, we’ll look in more detail at the Decision Table which we’ve used here.

FitNesse with .Net – Installing FitNesse

This entry is part 2 of 5 in the series FitNesse

FitNesse – The FitNesse application (wiki) with built-in web server.
FitSharp – Library that allows FitNesse to talk to .Net applications.

Options for Setup
There are a number of different ways to set up FitNesse. How you proceed will depend on the nature of your development process and personal preferences. We’ll look at the simplest possible installation in this post. In future posts we’ll look at the other possibilities.

For the purposes of this post we are going to focus on getting a single instance of FitNesse running on your development machine, so that you can learn how to use it. Later we’ll look at running FitNesse on a server, syncing tests on a server with local tests, and how to build FitNesse into a Continuous Integration process.

Local Installation
This approach involves installing FitNesse in a local location, e.g. C:\DevTools\FitNesse\.

Step 1. Download FitNesse

  • Download the fitnesse-standalone.jar file.
  • I like to rename the file to fitnesse.jar, which is what the file was called until recently.
  • Put the file in the location you want to run it from. I’ll use C:\DevTools\FitNesse

Step 2. Install FitNesse
Once the jar file is in place, installing it is just a matter of running it. On the first run, the contents of the file are extracted, creating the entire directory structure that makes up the FitNesse Wiki.

C:\DevTools\FitNesse>java -jar fitnesse.jar -p 9093

The command to start FitNesse can be placed in a batch file. I use a file called StartFitNesse.bat which I place in the same folder as the FitNesse .jar file.

The -p 9093 switch makes FitNesse run on port 9093. This isn’t necessary, if you don’t specify a port, then 80 will be used by default. I tend to run a number of different browser based tools, so I’ve gotten into the habit of assigning each one a Port number.

Assuming you have java installed and on your path the command above should run.. On the first run you should see a message confirming that it is unpacking FitNesse.

Step 3. Check that it’s working.
When FitNesse is running you can view it using your browser, by visiting


FitNesse switches

If you want to get a little clever you can try out some of the optional switches that configure FitNesse. We’ll poke into some of these in later posts.

Usage: java -jar fitnesse.jar [-pdrleoa]
        -p <port number> {80} or {9123 if -c}
        -d <working directory> {.}
        -r <page root directory> {FitNesseRoot}
        -l <log directory> {no logging}
        -e <days> {14} Number of days before page versions expire
        -o omit updates
        -a {user:pwd | user-file-name} enable authentication.
        -i Install only, do not run fitnesse after install.
        -c <command> Run the command (same as restful url) and then exit.

Return status is the number of test pages that failed as a result of the command.

Assuming you’ve done everything right, your browser should load the FitNesse Homepage. Congratulations, you have installed FitNesse. It’s a Wiki application running in it’s own little web server. You can play around, follow the links and see where they take you.

With FitNesse running, the next challenge is to write some tests and execute them against some .Net code. To do that we need to install FitSharp.

Step 4. Install FitSharp

  • download the zip file.
  • Extract the contents of the zip file you downloaded into a folder of your choice. E.g. as a sub folder of FitNesse C:\DevTools\FitNesse\Fitsharp.

Once you’ve extracted FitSharp, you’re done. When the time comes to use it, we’ll tell FitNesse where to find it. We won’t write any .Net code yet, we’ll get to that in the next post. This is just about getting everything set up.

One installation per project
Here we’ve installed FitNesse in a local folder and we can use this one installation for any number of projects. Jeff Kwak describes an alternative in which we have a separate instance of FitNesse for each project or solution. A nice feature of that approach is that the Wiki and all the related libraries automatically fall under source control.

I liked this approach a lot when I first saw it, but having played with the various options for a while, I prefer one installation of FitNesse with pages for the various projects. That’s the approach I’ll use for the remaining posts. I’ll meet you back here for our next post, when we actually get down to business and write some code.

FitNesse with .Net – What is FitNesse?

This entry is part 1 of 5 in the series FitNesse

Why another tutorial on installing and using FitNesse with .Net? Well, because I had a lot of trouble installing and using FitNesse with .Net. That may be an issue with the existing tutorials, or, it be an issue with me. Hopefully with these posts I can spare you some of the pain I encountered.

First things first. The source for all things FitNesse is here. There you’ll find lots of tutorials, samples and other useful info. In fact, if you stick at it you’ll get up and running using just the information on that site, but if you’re in any way like me you may find you slip off the happy path a few times. That’s where the tutorial you’re reading comes in.

Before you wrap your head around FitNesse, it helps to have an understanding of where it came from. The Framework for Integrated Testing (FIT) was developed by Ward Cunningham. The origins of FIT go back to a project where Cunningham discovered that he could allow users to enter test scenarios into a spreadsheet, and with a bit of coding he could make those test scenarios execute against the project code.

FIT is a publicly distributable version of that idea. Requirements can be written in a standard word document. Specific “examples” or “Test Cases” are created as Tables, and FIT enables us to hook that document up to executable code, run the tests and actually insert the results back into the Word Document.

FitNesse takes this notion a step further and provides a self contained Wiki complete with it’s own web server. Requirements can be entered into the Wiki or edited by anyone with access. A number of styles of tables give a means of demonstrating requirements using Sample Data. Like FIT, the FitNesse wiki can be “run” against our code base, and the results of tests inserted back into the Wiki.

Fit and Slim
Originally FitNesse used Fit as a means of hooking the tests (in the Wiki) up to executable code. Later the developers of FitNesse set about replacing Fit. The result was Slim. While you can still use FIT with FitNesse, I will focus on Slim, I think it’s an improvement on FIT and works better with .Net. There is a discussion of Fit and Slim here.

FitNess in Action
So, enough waffle, what does FitNesse look like in practice? The following screenshot shows a Decision Table, just waiting to be run. A Decision Table is one of a number of different types of tables that Slim provides as a means of illustrating requirements through tests.

We’ll get to what all of this means in due course, but for now, it’s a table with three inputs and an expected Result. The eagle eyed among you will notice that one of those examples looks like it’s expecting the wrong result. When we run our tests that should give us something worthwhile to look at.

Take a look at the buttons, they all do interesting things, but for now we’re just interested in the ‘Test’ button. If we click it, our FitNesse tests spring to life, execute themselves against our code base, fill in the results in our table, and highlight the passes and fails in green and read. Or to say it more simply with a picture…this happens…

Notice that one of the tests turns red. Dividing 6 by 3 doesn’t give 3. This isn’t highlighting a bug in the code, it’s highlighting a bug in the test, which can and does also happen from time to time. The point here is that when our expectations aren’t met, we’re told about it and can figure out whether it’s the code or the expectation that’s wrong.

What just happened?
How did the table know where to find our code and execute it?
How does it communicate with our code? How does it pass parameters and getting back results? What’s that text above the test table?

These and many more questions will be answered during this series of posts. I hope you’ll stay with me. Next up, we install FitNesse and a few more bits and pieces that we need to make it play nice with .Net languages like C#.

Fit Tables and Slim Tables
Before I close this post let me return to that issue of Fit vs Slim once more. A big practical difference between the two is the types of tables we can use to define tests. In the example above we used a Decision Table which is a Slim. The Equivalent Fit table is known as a ColumnFixture.

We’ll be using the Slim tables in these posts, but it’s worth being aware of Fit in case you see any examples of Fit tables.

Fluent Mocking

In which our hero shouts “Hold on thar pilgrims” at those who would hate Mocking Frameworks.

Here’s a scenario (for once not a hypothetical scenario, this is a real system I worked on). You’re building a wizard based app. To be more accurate you’re building lots of wizard based apps, so you’ve extracted all the wizardy stuff up into it’s own classes. Your apps can now focus on actual bread and butter functionality. When I say ‘You’ I mean ‘I’ but this is a writing device that sucks you into the narrative. I bet deep down you already care a little bit about how these Wizards turned out.

Two of the objects in your Wizardy Stuff code are a ‘Wizard’ and a ‘WizardStep’. A Wizard obviously contains a number of WizardSteps. You get the idea.

There are quite a few tests that we can write to make sure that navigation works. A Wizard has a current step, Moving Next or Previous should increment or decrement the current step. Moving next on the last step causes the Wizard to finish. It’s all very simple, and what you’d expect from a wizard.

Let’s look at an example of the kind of tests we might have to write, and what it means in terms of mocks and stubs. We have a requirement that says that when the user clicks ‘Move Next’ the current step gets to validate itself and decide whether it will allow the Move Next to happen. If it returns false, the Wizard will refuse to allow the user to move on.

To test a feature like this we can do the following:

  • Create a wizard with one step
  • Use a stub for step1 that returns false when the OKToMoveNext method is called
  • Start the wizard
  • Assert that we’re on the first step
  • Attempt to move next
  • Assert that we’re still on the first step

After the attempt to MoveNext we should still be on step1 (because step1 returns false when asked to validate itself).

We can implement the test in various ways. A key issue is how to implement the stub for step1 that simulates a step failing validation. Here’s one example, using the Moq Framework:

	// Listing 1
        public void Validation_CanPrevent_MoveNext()
            Mock<IWizardStep> step1 = new Mock<IWizardStep>();
            step1.Setup(s => s.OKToMoveNext()).Returns(false);

            Wizard wizard = new Wizard()

            Assert.AreEqual(step1.Object, wizard.CurrentStep);


            Assert.AreEqual(step1.Object, wizard.CurrentStep);

I don’t like this code. It’s too busy. There’s too much “stuff” that’s related to the mocking framework. The intent of the test might be discernible, but only just. The shaded lines in particular need a second or third glance to make sure you’re reading them right. Our intent is to create a stub wizard step that can’t move next. Our test should be screaming that intent so clearly that it cant be missed by someone reading the code.

I suspect that scenarios like this are one of the reasons why some developers find themselves edging back towards hand-rolled mocks and stubs. The equivalent code using hand-coded classes is much simpler and the intent of the test is clearer:

	// Listing 2
        public void HM_Validation_CanPrevent_MoveNext()
            IWizardStep step1 = new WizardStepThatIsNotOKToMoveNext();

            Wizard wizard = new Wizard()

            Assert.That(wizard.CurrentStep == step1);


            Assert.That(wizard.CurrentStep == step1);

The shaded code tells most of the story. Because we’re creating a simple class for a specific purpose, we can be very explicit with our naming.

Although listing 2 is an improvement over the code we produced using the Moq mocking framework, it’s not without it’s troubles. Our suite of tests is going to need a lot of different mocked WizardSteps to cover the various scenarios. Many will be very similar, or will have parts that are identical to parts of others. For example, we might have half a dozen version of the class that need to prevent a user Moving Next, but each may need to do that in conjuction with some other different behaviour.

We could try to make our Handmade mocks more intelligent, but that’s a slippery slope. Once you start adding in “one more little tweak, to facilitate one more test”, you quickly find yourself with a mock that’s more complex than the code you’re trying to test.

One interesting option is to go back to using our Mocking Framework, but hide the messiness of it behind a slightly nicer abstraction. Imagine being able to write a test like the one in Listing 3:

	// Listing 3
        public void step_can_stop_move_next()
            IWizardStep step1 = new MockWizardStep()

            Wizard wizard = new Wizard()

            Assert.AreEqual(step1, wizard.CurrentStep);


            Assert.AreEqual(step1, wizard.CurrentStep);

This is a fluent style interface, but behind the scenes it’s doing all the same stuff that our first test did. The beauty of a mocking framework is that you can assemble the functionality you desire at runtime, rather than needing to code a specific class for the specific case you want to test. Once you’ve written the Factory that spits out mocks, you can use it to spit out other variations of the MockWizardStep:

	// Listing 4
            IWizardStep step1 = new MockWizardStep()

            IWizardStep step1 = new MockWizardStep()

Once you have the fluent interface in place it gets a lot easier to create exactly the right mock for the scenario you want to test. The test becomes clearer, and to a certain extent you’ve abstracted your tests away from the specific mocking framework that you are using.

It’s not all ribbons and bows. One problem is that you have to actually build the fluent interface. You can’t really make a generic one of these. A fluent interface by it’s nature is a Domain Specific Language. You implement a language based on the properties of the objects you’ll be mocking.

Creating the Fluent Interface isn’t a particularly complicated task (see Listing 5), but it’s enough work that you need to think carefully about whether it will pay for itself. The example here is also artificially simple, showing only a few stub methods. When you get into creating a fluent interface that allows you to configure Mock behaviour, like verifying method calls etc, things could get a little hairy.

It’s worth looking more closely at the shaded code in Listing 5, we what appears to be a readonly property, modifying fields within the class. What madness is this? It’s nothing really, just a trick used in constructing fluent grammars to avoid having parenthesis after every term in a statement.

    // Listing 5
    public class MockWizardStep
        private Mock<IWizardStep> _step;
        private bool _thatCan = true;

        public MockWizardStep()
            _step = new Mock<IWizardStep>();

        public MockWizardStep ThatCan
                _thatCan = true;
                return this;

        public MockWizardStep ThatCannot
                _thatCan = false;
                return this;

        public MockWizardStep MoveNext
                _step.Setup(v => v.OKToMoveNext()).Returns(_thatCan);
                return this;

        public MockWizardStep MovePrevious
                _step.Setup(v => v.OKToMovePrevious()).Returns(_thatCan);
                return this;

        public IWizardStep Object()
            return _step.Object;

        public Mock<IWizardStep> Mock()
            return _step;

So, where does that leave us? Are mocking frameworks saved from those who would hate them? Well, probably not, but for everyone else here’s one more tool in your toolbox for that day when the perfect scenario presents itself.

So Over Mocking Frameworks

In which our hero peddles more of the stuff that wasn’t good enough to make it into his TDD Session, and passes it off as an interesting blog post. Welcome to the blog equivalent of the “extras” section of a DVD.

During the course of preparing and presenting my session on Test Driven Development, I had quite a few interesting conversations with quite a few interesting people. Some were the face to face kind of chats that you inevitably have after presenting a session, some were via email.

One theme that popped up more than once was the notion of being “over” mocking frameworks. And when I say “over” I mean it in the “girlfriend from college that you’d rather not see any more” sense of the word.

It appears that when it comes to mocking, TDD practitioners go through a number of phases.

  • Ignorance – How to I test this object, it has all these dependencies?
  • Interest – Hmmm I can create classes that implement the same interface as a dependency.
  • Excitement – Holy crap, mocking frameworks are da shizzle, I want to use them everywhere.
  • Hmmm – Why is it complicated to do this with a mocking framework. A hand coded class would be so much simpler.
  • Disillusionment – Holy crap, mocking frameworks are a pain, I don’t want to use them anywhere.
  • Righteous Indignation – Dude! You’re using Mocking Frameworks? that’s like so 2009.
  • Perspective – Mocking frameworks, handrolled? Meh! Both have their place

As with virtually everything else in life, extreme views for or against Mocking frameworks are unlikely to be helpful to anyone. They’re a tool. Ignoring them completely (or consciously not using them) is no more helpful than surrendering to them and using them blindly.

In a future post I’ll look at how to mitigate some of the issues that cause people to “get over” Mocking Frameworks. I’ll also look at some of the issues that need to be addressed when using hand rolled mocks and stubs.

Retro Fitting Unit Tests to Legacy Code

This post references a StackOverflow thread which you can read

One of the problems with TDD is that those who try it, often begin by booting up NUnit or something similar, writing a few trivial tests to get the lie of the land, then instead of doing TDD (i.e. Writing a test and then writing some code to make the test pass) they do something much much harder, under the mistaken impression that it will actually be a way to ease themselves into TDD.

They do what I did, they start out by trying to write some unit tests for existing code. Either a past project, or more likely the project they are currently working on. They quickly discover that these projects are (from their perspective) virtually impossible to test.

The reason why is obvious, 1) They are new to writing automated tests, which is a tricky enough skill to master, but more importantly 2) They are new to writing testable code which is actually a significantly bigger challenge than writing tests. The chances that their old projects contain testable code is virtually nill.

So, our protagonist is actually starting their journey to TDD with an obstacle that is actually beyond the ability of some seasoned TDD practitioners. Think a video game with the ultimate Boss level as the very first thing you do, before you learn the controls or understand much of anything about the game. That right there is a game that you’ll probably throw in the bin after about an hour, if you last that long.

In my research for my TDD session at #dddsw I found lots of interesting questions, blogs and articles, most of which I didn’t have time to fully discuss during the session, but I’ll point you in the direction of some of them over the next few days/weeks.

The first is a Stack Overflow discussion on how to write automated tests for a complicated function with lots of dependencies.

It’s notable because it’s not an uncommon problem, and the answers cover the usual spectrum from practical solutions to pragmatic advice to questioning the validity of the original question etc.

It’s also notable because Uncle Bob contributes an interesting Step By Step on how to add tests to existing code (in an kludgy way) and then how to refactor both the original code and the kludgy test handling.

Original Thread Here