Navigate / search

Aim for DRY, but be willing to fall short.

I’m not going to rehash the reasons why “Don’t repeat yourself” (DRY) is a good thing, I’ll assume you know why duplicating code is bad.

Strictly speaking DRY isn’t really about repeating code, it’s more about representing the same “Information” or “Knowledge” in different places. For that to happen the code doesn’t actually have to be the same.

Conversely, duplicated code doesn’t always represent duplicated knowledge or information, completely different concepts can sometimes be represented by virtually identical code.

Mathias Verraes recently wrote a really good blog post on this very issue, it’s well worth a look.

This post is about aiming for DRY, but deliberately coming up short.

I’ve been adding some NUnit tests to an existing system recently and I kind of liked the way they turned out, despite the fact that I duplicated some code.

The following is heavily modified code, I can’t show the original, but it gets the point across. Please don’t read into anything you see about credentials or security, this code is one step away from Widgets and Wotzits, it’s NOT REAL CODE.

    class Describe_Club_Membership
    {
        [Test]
        public void A_User_Can_Join_The_Club()
        {
            UsingCredentials("appName", "appKey");
            var userId = GetUserId("someUsersEmail@example.com");

            EnsureUserIsNotAMember(userId)

            JoinClub(userId);
            Assert.That(IsAMember(userId));
        }

        [Test]
        public void A_User_Can_Leave_The_Club()
        {
            UsingCredentials("appName", "appKey");
            var userId = GetUserId("someUsersEmail@example.com");

            EnsureUserIsAMember(userId)

            LeaveClub(userId);
            Assert.That(IsNotAMember(userId));
        }

The entire contents of the tests are written using functions that exist only for the purpose of making the tests readable. In a sense these few functions define a Domain Specific Language. Code within any function (but particularly within a test) should always be written at the same level of Abstraction, would should never have code like the following in a test.

    class Describe_Club_Membership
    {
        [Test]
        public void A_User_Can_Join_The_Club()
        {
            var credentialsFactory = new CredentialsFactory("Membership");
            var credentials = credentialsFactory.CreateDefaultCredentials("appName", "appKey");

            var registrationRepo = new RegistrationsRepository(credentials);
            var userId = registrationRepo.GetUserByEmail("someUsersEmail@example.com").FirstOrDefault().Id;

            var binding = new BasicHttpBinding();
            var membershipEndPoint = new EndpointAddress(ConfigurationManager.AppSettings["..."]);
            
            var membershipService = new MembershipServiceClient(binding, membershipEndPoint);

            ... etc...   
        }

You get the idea, everything that needs to be done, is in the test, from pulling information out of Repositories, to reading Configuration Files, to configuring services endpoints to actually calling services, and on and on.

I don’t know about you, but I prefer the first code sample to the second.

Those functions that make up the Domain Specific Language in the first tests, have to go somewhere, and as you can see from the second example, some of them involve a little bit of work. Look again at the first code sample, you’ll see that I have a function called ‘UsingCredentials’ but it doesn’t return credentials. If it did I could pass them into the subsequent functions that need credentials, but in my DSL it’s enough to state the credentials I want to use. Passing the credentials and all the other dependencies around would unnecessarily clutter up the tests.

So, clearly the credentials are being saved somewhere by the ‘UsingCredentials’ function and then subsequent functions can use them.

    class Describe_Club_Membership
    {
        private Credentials _credentials;

        [Test]
        public void A_User_Can_Join_The_Club()
        {
            UsingCredentials("appName", "appKey");
            var userId = GetUserId("someUsersEmail@example.com");

            EnsureUserIsNotAMember(userId)

            JoinClub(userId);
            Assert.That(IsAMember(userId));
        }

        // Test Fixture DSL Commands
        private void UsingCredentials(string appName, string appKey)
        {
            _credentials = CredentialsHelper.GetCredentials(appName, appKey);            
        }

        ...

The UsingCredentials function is actually just a one liner, the heavy lifting is done elsewhere in a helper class. The job of getting credentials may be needed by lots of TestFixtures so I want that logic in a shared component, not duplicated. We’re heading in the right direction of DRY.

So, what then is the point of the UsingCredentials function we see here?

Put simply, I like the way it makes the tests read. I could have used this one liner, and others like it in the test, but a test made up of a series of these kinds of calls is more cluttered and it gives the impression that these helper classes may be significant to the test. I don’t want to give that impression.

I want to declutter the test so that only the logic being tested remains. Wrapping this and other one liners in tiny DSL style commands sends a message that the details of how the helpers are called is not as important than the logic being tested.

But what then if I want to use the same Helper from other Test Fixtures, aren’t I going to have to duplicate the little functions that wrap the one liners?

Yes I am.

This is where I deliberately fall short of DRY.

For one of my fixtures I have 7 of these tiny functions. They vary in complexity but none contain more than one line of code. Code that I do not want to see directly in my tests. In another fixture, I use three of those same wrapper functions, and I’ve duplicated the three that I need.

How could I make use of these DSL functions without duplicating them? One benefit of the wrapper functions is that they can access the credentials or any other member of the fixture without it being passed as a dependency. If I move the wrapper functions out I’m basically back to calling the helper functions and needing to pass all dependencies. In short, the wrapper functions no longer serve any purpose.

I could define the helpers and the credentials in a base class and inherit my test fixtures from that. That is in fact a really nice solution, it’s DRY, the Tests look just as nice and the Test Fixtures don’t even have the tiny wrapper functions in them.

If you wanted to go with the inheritance option I’d be hard pushed to make a case against it. I just don’t like inheritance and I really don’t like it in test suites.

Irrational as it may be I prefer to have these tiny functions so my tests can be as clean as possible, but I’m willing to fall a little short of DRY rather than use inheritance.

If someone is curious when looking at a test and wants to see what a function does or where credentials come from, it’s right there, in the fixture, no climbing an inheritance hierarchy.

As soon as you start using inheritance it sucks you in, you start adding more to the base class, or an extra level of inheritance here and there. It gets messy real fast.

What will happen when not all of the test Fixtures need Credentials? When some subset of fixtures need some other shared member? The Base class starts to become the union of all needs rather than the intersection. And for what? So we can avoid duplicating a handful of one line functions that are unlikely to change. Even if they do change it’s going to be trivial, perhaps a new argument to the helper function.

The key points for me are:

  1. Keep your tests as free of clutter as possible, nothing should remain but the logic being tested, written at a consistent level of abstraction.
  2. If necessary define a tiny Domain Specific Language for your tests as simple one liner functions which call to the real shared code, kept elsewhere.
  3. Keep the DSL functions you need right there in the Test Fixture, duplicate them if necessary. Don’t try to over engineer your DSL using inheritance or any other clever tricks.

The third point about inheritance is maybe up for debate, but I don’t thing the first two points are.

Annotate your code with TestCases

I’ve noticed myself doing something when I code that I had never really thought about, it just kind of happened. When I write a test for a very particular type of code, I find myself coding the function right there in the test. Here’s some code that kind of illustrates what I mean.

[TestCase(new byte[] { 97, 98, 99, 32, 100, 101 }, Result = "616263206465")]
public string AsciiBytesToHexString(byte[] asciiBytes)
{

}

Now, there are all sorts of reasons not to like this as a unit test. Why so many bytes? two would probably suffice. Is the fact that one of the bytes represents a space significant? Could the test name be better?

All fine questions and in the past I might have obsessed about them.

Let me back up for a second and see what I’m actually doing here. I want a function that can take a byte array and output a hex string. That is all I want. This isn’t a particularly difficult task, but there are lots of these little tasks where I might not be 100% sure of the C# syntax, or I just want a quickly runnable sanity check that the code behaves like I want, so, I write a test.

With the TestCase in place, I can code the function. I don’t know or care whether this is the perfect code for the job, whether there is some C# command that does all this for me, I just want to get my test passing. If I can improve it later I will.

[TestCase(new byte[] { 97, 98, 99, 32, 100, 101 }, Result = "616263206465")]
public string AsciiBytesToHexString(byte[] asciiBytes)
{
    var sb = new StringBuilder();

    foreach (var asciiByte in asciiBytes)
        sb.Append(asciiByte.ToString("X"));

    return sb.ToString();
}

Now, strip away the TestCase attribute and you’ve basically got the function you wanted. It takes in a byte array and returns a string. The Test dissolves into the background.

In the past I might have written a test somewhere in a test fixture, then created the function I actually want in a Test-Driven fashion to make the test compile and ultimately pass. That gives me a function in one part of my code base, and the tests somewhere else, perhaps in an assembly that ends with *.Tests.dll.

Having noticed myself coding full implementations inside tests, I started thinking about what I do next. In this case, I would probably cut and paste this method from the Test Fixture into whatever home I think it belongs.

I might or might not leave behind a test calling the function in it’s new home. If I was just sussing out syntax I’m not sure having a test separate from the function really pays for itself. This isn’t code I expect to break or even ever be refactored significantly.

Looking at that function with the TestCase attribute It occurs to me that there’s no reason why I can’t take that attribute with me when I move the function to it’s ultimate home. Doing so means that the tests exist IN the production code, rather than as some separate entity.

I seem to straying in the direction of code contracts here, but it seems such an obvious step I’m astonished It hadn’t occurred to me sooner.

When you are looking through production code, you can try a find usages on a function to see if it’s referenced by any tests, but how much better is it to see sample inputs and outputs right there above a function in it’s natural habitat.

This might not be something you would use for every function, but for those small discrete functions that can be illustrated perfectly with one or two test cases this seems like a really useful approach.

And let’s be honest. If a function can’t be illustrated with a few test cases, isn’t worth asking why not?

Bowling Game Kata in F#

This entry is part 5 of 11 in the series Learning to think Functionally

I’m on an ongoing quest to get competent with F#. I’m also on an ongoing quest to get competent with TDD. Interestingly until now those two quests hadn’t crossed paths. I had written no unit tests in F#. Why you might ask?

When I started writing Unit Tests I found the biggest win wasn’t the design that tests drive, nor was it catching regression bugs. The biggest win was the huge saving on time spent in the debugger.

When I started playing with F# using the REPL, I found that I wasn’t spending any time in the debugger. I mean literally none. After a few weeks of playing with It I actually consciously tried using the debugger to see what it was like. To date I still have had no problem in F# that required me to debug the code.

I recognise that that’s possibly a result of working on “relatively” simple code. I’d hope code would always be simple, but, there will probably come a time when I’ll need to either debug code, or use tests to avoid debugging. So, it’s time to bring F# and TDD together.

The Bowling Game kata seemed like a good start. The attraction of this Kata is that it seems perfectly set up for a functional solution. You have an input (a list of scores from frames) and a desired output (the score for that game) and your job is to write a transformation from one to the other. A list of tuples seems like a really nice way to represent the rolls in a game of bowling, and, I initially thought I may be able to write some sort of ‘fold’ or ‘reduce’ function that would reduce the list of tuples to the correct score. As you’ll see, it didn’t quite work out like I had hoped.

Let’s start with a test for the simplest type of games, one with no Spares or Strikes.

    [<TestCase(Result=30)>]
    member x.RegularGame() =
        let rolls = 
            [(1,2); (1,2); (1,2); (1,2); (1,2); (1,2); (1,2); (1,2); (1,2); (1,2)]
        ScoreGame rolls

My first thought for this was to just use a fold function.

let ScoreGame (frames: List<int * int>) =
    List.fold (fun score frame -> score + fst frame + snd frame) 0 frames 

This does get the test passing, but having played with this I found it virtually impossible to add support for strikes and spares. I’m going to back up and show you the route I eventually settled on, but please feel free to let me know if you manage to make something of the ‘fold’ approach.

let rec ScoreGame (frames: List<int * int>) =
    match frames with
    | [] -> 0
    | frame::rest -> fst frame + snd frame + ScoreGame rest 

This is essentially the same as the fold, but the pattern matching allows us a way of handling special cases. Let’s take a look at one of those now, Spares.

    [<TestCase(Result=38)>]
    member x.ContainsSpares() =
        let rolls = [(1,2); (1,2); (1,2); (5,5); (1,2); (1,2); (1,2); (1,2); (1,2); (1,2)]
        ScoreGame rolls

A frame is a Spare when the two rolls add up to 10. If the first frame on it’s own is 10 then that’s a Strike. We’ll ignore Strikes for now. The following code gets us to green.

let rec ScoreGame (frames: List<int * int>) =
    match frames with
    | [] -> 0
    | frame::rest when fst frame + snd frame = 10
        -> 10 + fst rest.Head + ScoreGame rest
    | frame::rest 
        -> fst frame + snd frame + ScoreGame rest 

When a Spare occurs, the first subsequent roll is added as a bonus.

We can refactor a little bit to make things clearer.

let ScoreFrame (roll:int * int) =
    fst roll + snd roll

let IsASpare (frame:int * int) =
    ScoreFrame frame = 10

let rec ScoreGame (frames: List<int * int>) =
    match frames with
    | [] -> 0
    | frame::rest when frame |> IsASpare
        -> 10 + fst rest.Head + ScoreGame rest
    | frame::rest 
        -> ScoreFrame frame + ScoreGame rest

This is all fairly straightforward so far. There is one little edge case for Spares and that is how they are handled when they occur in the 10th frame. As mentioned above, when you score a Spare the first roll of the subsequent frame should be added as a bonus. The 10th frame is the final frame, so to allow for bonuses on strikes or spares bowled in the 10th frame, up to two additional balls can be rolled. I handle this by adding an 11th tuple when either a strike or spare is scored in the 10th frame, and scoring accordingly.

    [<TestCase(Result=38)>]
    member x.EndsOnASpare() =
        let rolls = 
            [(1,2); (1,2); (1,2); (1,2); (1,2); (1,2); (1,2); (1,2); (1,2); (5,5); (1, 0)]\\
        ScoreGame rolls

When a strike or spare occurs in an earlier frame the subsequent rolls are counted as a bonus, but they are also scored in their own right. This is different for the “11th frame”. This exists purely for the purposes of determining the bonus in the 10th frame, the rolls are not added to the score in their own right.

We need to keep track of what frame we’re on, so we handle the bonus for Strikes and Spares in the 10th frame correctly. One way to do this would be to turn the tuples into triples by adding a frame number to each one. I don’t like adding that burden to the input data, particularly when it’s relatively easy to have the code keep track itself.

let rec ScoreFromFrame thisFrame (frames: List<int * int>) =
    match frames with
    | [] -> 0
    | frame::rest when frame |> IsASpare && thisFrame < 10
        -> 10 + fst rest.Head + ScoreFromFrame (thisFrame+1) rest
    | frame::rest 
        -> ScoreFrame frame + ScoreFromFrame (thisFrame+1) rest

I’ve added a parameter ‘thisFrame’ that indicates which frame is being scored. For frames prior to the 10th frame we add the first roll of the next frame as a bonus, then score from the next frame onwards as normal. For frame 10 we just add the score for frame 11 (if it exists).

I’ve also renamed the function from ‘ScoreGame’ to ‘ScoreFromFrame’. These changes would break all of our tests. We could go back and change each test, but actually I quite like the way the tests are written. When we want the score of a game, we should be able to call ScoreGame and simply pass it a list of frames.

The following would obviously work as a way of preserving the interface that the tests rely on

let ScoreGame (frames: List<int * int>) = 
    ScoreFromFrame 1 frames

But, with a bit of currying there’s an even nicer solution

let ScoreGame = ScoreFromFrame 1

Time for another test, what happens if we score a Strike?

    [<TestCase(Result=40)>]
    member x.ContainsAStrike() =
        let rolls = 
            [(1,2); (1,2); (10,0); (1,2); (1,2); (1,2); (1,2); (1,2); (1,2); (1,2)]
        ScoreGame rolls

A strike is a frame where all 10 pins are knocked by the first ball. The bonus for a strike is the next two rolls.

let rec ScoreFromFrame thisFrame (frames: List<int * int>) =
    match frames with
    | [] -> 0
    | frame::rest when fst frame = 10
        -> 10 + fst rest.Head + snd rest.Head + ScoreFromFrame (thisFrame+1) rest
    | frame::rest when frame |> IsASpare && thisFrame < 10
        -> 10 + fst rest.Head + ScoreFromFrame (thisFrame+1) rest
    | frame::rest 
        -> ScoreFrame frame + ScoreFromFrame (thisFrame+1) rest

This doesn’t correctly calculate the bonus when we score two or more strikes in a row, as we can see from the next failing test.

    [<TestCase(Result=58)>]
    member x.TwoStrikesInARow() =
        let rolls = 
            [(1,2); (1,2); (10,0); (10,0); (1,2); (1,2); (1,2); (1,2); (1,2); (1,2)]
        ScoreGame rolls

The problem here is that after the first Strike we don’t calculate the bonus from the next two ‘Rolls’ which would be 10 and 1, we calculate from the two items in the next frame (10, 0), which isn’t correct. Let’s clarify exactly what we mean by “Next Two Rolls”

let IsAStrike (frame:int * int) =
    fst frame = 10

let NextTwoRollsFrom (frames: List<int * int>) =
    match frames with
    |this::next::rest when this |> IsAStrike && snd this = 0 ->
        10 + fst next
    |this::_ -> ScoreFrame this

let rec ScoreFromFrame thisFrame (frames: List<int * int>) =
    match frames with
    | [] -> 0
    | frame::rest when frame |> IsAStrike
        -> 10 + NextTwoRollsFrom rest + ScoreFromFrame (thisFrame+1) rest
    | frame::rest when frame |> IsASpare && thisFrame < 10
        -> 10 + fst rest.Head + ScoreFromFrame (thisFrame+1) rest
    | frame::rest 
        -> ScoreFrame frame + ScoreFromFrame (thisFrame+1) rest

We can wrap this all up with a test for a perfect game, which should pass with no further changes. For the record, here’s the full code, plus tests, including one or two minor readability tweaks.

module Bowling

let ScoreFrame (roll:int * int) =
    fst roll + snd roll

let IsAStrike (roll:int * int) =
    fst roll = 10

let IsASpare (frame:int * int) =
    ScoreFrame frame = 10

let NextTwoRollsFrom (frames: List<int * int>) =
    match frames with
    [] -> 0
    |this::next::rest when this |> IsAStrike && snd this = 0 ->
        10 + fst next
    |this::_ -> ScoreFrame this

let NextOneRollFrom (frames: List<int * int>) =
    fst frames.Head

let rec ScoreFromFrame thisFrame (frames: List<int * int>) =
    match frames with
    | [] -> 0
    | frame::rest when frame |> IsAStrike && thisFrame < 10
        -> 10 + NextTwoRollsFrom rest + ScoreFromFrame (thisFrame+1) rest
    | frame::rest when frame |> IsASpare && thisFrame < 10
        -> 10 + NextOneRollFrom rest + ScoreFromFrame (thisFrame+1) rest
    | frame::rest 
        -> ScoreFrame frame + ScoreFromFrame (thisFrame+1) rest

let ScoreGame = ScoreFromFrame 1


module BowlingTests

open NUnit.Framework
open Bowling

[<TestFixture>]
type BowlingTests() =

    [<TestCase(Result=30)>]
    member x.RegularGame() =
        let rolls = 
            [(1,2); (1,2); (1,2); (1,2); (1,2); (1,2); (1,2); (1,2); (1,2); (1,2)]
        ScoreGame rolls

    [<TestCase(Result=38)>]
    member x.ContainsASpare() =
        let rolls = [(1,2); (1,2); (1,2); (5,5); (1,2); (1,2); (1,2); (1,2); (1,2); (1,2)]
        ScoreGame rolls

    [<TestCase(Result=38)>]
    member x.EndsOnASpare() =
        let rolls = [(1,2); (1,2); (1,2); (1,2); (1,2); (1,2); (1,2); (1,2); (1,2); (5,5); (1, 0)]
        ScoreGame rolls

    [<TestCase(Result=40)>]
    member x.ContainsAStrike() =
        let rolls = 
            [(1,2); (1,2); (10,0); (1,2); (1,2); (1,2); (1,2); (1,2); (1,2); (1,2)]
        ScoreGame rolls

    [<TestCase(Result=58)>]
    member x.TwoStrikesInARow() =
        let rolls = 
            [(1,2); (1,2); (10,0); (10,0); (1,2); (1,2); (1,2); (1,2); (1,2); (1,2)]
        ScoreGame rolls

    [<TestCase(Result=40)>]
    member x.EndsOnAStrike() =
        let rolls = 
            [(1,2); (1,2); (1,2); (1,2); (1,2); (1,2); (1,2); (1,2); (1,2); (10,0); (1,2)]
        ScoreGame rolls

    [<TestCase(Result=300)>]
    member x.PerfectGame() =
        let rolls = 
            [(10,0); (10,0); (10,0); (10,0); (10,0); (10,0); (10,0); (10,0); (10,0); (10,0); (10,10)]
        ScoreGame rolls

It’s hardly worth mentioning but there’s one little thing that annoys me and that is the definition of a Spare. At the moment any frame with a score of 10 would elicit ‘true’ from the IsASpare function, this means that a Strike would get a true from that function.

Since we check for Strikes before Spares in the Pattern match, this issue doesn’t raise it’s head, but I’d like to make the definition of a Spare more water tight. This would have the added bonus of reducing the dependence of the pattern match on the order of the clauses.

We can modify the IsASpare function quite easily to express it accurately. This isn’t a hugely significant issue in a Kata, but in a business application where you are trying to express concepts in your domain, that little bit of ambuguity (and that isn’t a typo) could have serious implications.

let IsASpare (frame:int * int) =
    not(IsAStrike frame) && ScoreFrame frame = 10

Legacy Code Katas

I like Kata’s, I’ve get a lot out of them, but if I’m truly honest, they don’t really address one area of programming where I think I need practice, and that is in working with Legacy Code. In pondering this problem I came to the conclusion that I need a way of doing deliberate practice for legacy code work, and some variation of the Kata idea seems like it might work.

I should point out that this isn’t an original idea, there’s at least one StackOverflow question from 2009 asking about this exact topic. Nothing seems to have come out of it however. Perhaps there’s a reason for that.

There are practical reasons why Legacy Code Kata’s are difficult. I’m not going to go into them all now, but for starters a traditional Kata can be stated with a few sentences of English text, and the programmer can implement it in any language, with any tool chain.

Legacy Kata’s will likely require us to provide starting code, which immediately makes them harder to create and limits their audience. Special variations would need to be created for each language for example. Might there be a way of describing the problem to be solved in a language independent way? So that the solver creates the starting code? I don’t know.

To get the ball rolling, or illustrate the idea, I’m including here some code, that could form the basis of an exercise/kata. Along with some tasks that should be accomplished with the code. If you have any feedback as to whether there is any potential here for any kind of useful learning/practice then let me know your thoughts.

Legacy Code Kata

    public class SecurityManager
    {
        public static void CreateUser()
        {
            Console.WriteLine("Enter a username");
            var username = Console.ReadLine();
            Console.WriteLine("Enter your full name");
            var fullName = Console.ReadLine();
            Console.WriteLine("Enter your password");
            var password = Console.ReadLine();
            Console.WriteLine("Re-enter your password");
            var confirmPassword = Console.ReadLine();

            if (password != confirmPassword)
            {
                Console.WriteLine("The passwords don't match");
                return;
            }

            if (password.Length < 8)
            {
                Console.WriteLine("Password must be at least 8 characters in length");
                return;
            }

            // Encrypt the password (just reverse it, should be secure)
            char[] array = password.ToCharArray();
            Array.Reverse(array);

            Console.Write(String.Format("Saving Details for User ({0}, {1}, {2})\n",
                username,
                fullName,
                new string(array)));
        }
    }

Given the code above, do the following:

  1. Break the dependency on the Console
  2. Get the password comparison feature under test
  3. Get the password validation feature under test
  4. Add a feature to allow different encryption algorithms to be used

Thoughts? Comments? Would a collection of exercises like this be a useful resource, or a waste of time?

The Anagrams Kata

The following is my C# implementation of the Anagrams Kata as described on cyber-dojo.com

Write a program to generate all potential
anagrams of an input string.

For example, the potential anagrams of “biro” are

biro bior brio broi boir bori
ibro ibor irbo irob iobr iorb
rbio rboi ribo riob roib robi
obir obri oibr oirb orbi orib

Let’s write a test.

        [Test]
        public void NoCharacters()
        {
            var expected = new List<string> {""};
            Assert.That(Anagrams.Of(""), Is.EqualTo(expected));
        }

As is almost always the case, we start with the degenerate case of an empty string. We don’t do this solely to ensure the degenerate case is handled (that’s part of it), but with this first test we’re thinking about the API of our new code.

You can see from the highlighted line that the Function we’re writing will be a static method called ‘Of’ on a class called ‘Anagrams’, which allows us the somewhat fluent usage ‘Anagrams.Of(s)’. This is simple Test Driven Design, we’re writing tests as if the desired code already exists, which in theory gives us the best API we could possibly hope for.

Let’s make that test pass. We’ll need a Class, a Method, and we’ll return a literal that satisfies the test.

    public class Anagrams
    {
        public static List<string> Of(string s)
        {
            return new List<string> {""};
        }
    }

We have GREEN. We might have been tempted to just return s and be done with it. It would have passed the test, and it would have handled the case of one character strings also. Thinking about passing tests that we haven’t even written yet suggests we’re getting ahead of ourselves. Let’s write the test for the one character example.

        [Test]
        public void OneCharacter()
        {
            var expected = new List<string> { "A" };
            Assert.That(Anagrams.Of("A"), Is.EqualTo(expected));
        }

Now we’ve got a failing test, let’s get it passing. We can return ‘s’ as mentioned above, and both our tests would pass. It’s ok to take these kinds of steps, if a test fails unexpectedly we can revert the changes and try again a little more slowly.

For the sake of the exercise, let’s go slow for now and look at a technique that will serve us well later when things are more complicated. We’ll isolate the existing working code, make the new test pass with a branch in the code, then try to eliminate the branch. Here’s a way of getting both tests passing.

        public static List<string> Of(string s)
        {
            if(s == "")
                return new List<string> {""};

            return new List<string>{"A"};
        }

The ‘if’ statement handles the empty string case, so our new code doesn’t break it. We use a literal value “A” to get the new test passing as simply as possible. This leaves us with duplication between the literal value “A” in the test and the same value in the code. We can remove the duplication by generalising the solution for One character, returning s is the more general form of returning “A”.

        public static List<string> Of(string s)
        {
            if(s == "")
                return new List<string> {""};

            return new List<string>{s};
        }

It’s clear now that returning s will make both our tests pass, so let’s refactor.

        public static List<string> Of(string s)
        {
            return new List<string>{s};
        }

Time for another test. How about two characters?

        [Test]
        public void TwoCharacters()
        {
            var expected = new List<string> { "AB", "BA" };
            Assert.That(Anagrams.Of("AB"), Is.EqualTo(expected));
        }

Let’s repeat the same trick of protecting the existing working code with an if statement, and making the test pass using the simplest possible implementation.

        public static List<string> Of(string s)
        {
            if(s.Length<=1)
                return new List<string>{s};

            return new List<string>
                       {
                           "AB", 
                           "BA"
                       };
        }

We’re back to having duplication between our test and our code, let’s break that.

        public static List<string> Of(string s)
        {
            if(s.Length<=1)
                return new List<string>{s};

            return new List<string>
                       {
                           s, 
                           s.Substring(1,1) + s.Substring(0,1)
                       };
        }

That’ll work for any strings from 0 to 2 characters. Next test, three characters.

        [Test]
        public void ThreeCharacters()
        {
            var expected = new List<string> { "ABC", "ACB", "BAC", "BCA", "CAB", "CBA" };
            Assert.That(Anagrams.Of("ABC"), Is.EqualTo(expected));
        }

And to make this pass? You should know the ropes by now. Isolate existing code, and hard code a solution.

        public static List<string> Of(string s)
        {
            if (s.Length <= 1)
                return new List<string> { s };

            if(s.Length == 2)
            {
                return new List<string>
                       {
                           s, 
                           s.Substring(1,1) + s.Substring(0,1)
                       };
            }

            return new List<string>
                       {
                           "ABC", 
                           "ACB", 
                           "BAC", 
                           "BCA", 
                           "CAB", 
                           "CBA"
                       };
        }

There’s a pattern emerging here. Lets split up the strings to make it more clear.

            return new List<string>
                       {
                           "A" + "BC", 
                           "A" + "CB", 
                           "B" + "AC", 
                           "B" + "CA", 
                           "C" + "AB", 
                           "C" + "BA"
                       };

We can replace the first character on each row.

            return new List<string>
                       {
                           s.Substring(0,1) + "BC", 
                           s.Substring(0,1) + "CB", 
                           s.Substring(1,1) + "AC", 
                           s.Substring(1,1) + "CA", 
                           s.Substring(2,1) + "AB", 
                           s.Substring(2,1) + "BA"
                       };

What has that acheived? We still have literal values on each line. Well, we do, but they look famililar. “BC” and “CB” look like the anagrams of “BC”. Same applies to “AC”, “CA”, and “AB”, “BA”. We’ve discovered that part of the job of generating anagrams for three characters is to generate anagrams for two characters. Let’s see if we can make that explicit.

            return new List<string>
                       {
                           s.Substring(0,1) + Anagrams.Of("BC")[0], 
                           s.Substring(0,1) + Anagrams.Of("BC")[1], 
                           s.Substring(1,1) + "AC", 
                           s.Substring(1,1) + "CA", 
                           s.Substring(2,1) + "AB", 
                           s.Substring(2,1) + "BA"
                       };

If we get Anagrams.Of(“BC”) we’ll get two results. The first will be “BC” the second will be “CB”. We can repeat this change for the remaining literal values.

            return new List<string>
                       {
                           s.Substring(0,1) + Anagrams.Of("BC")[0], 
                           s.Substring(0,1) + Anagrams.Of("BC")[1], 
                           s.Substring(1,1) + Anagrams.Of("AC")[0], 
                           s.Substring(1,1) + Anagrams.Of("AC")[1], 
                           s.Substring(2,1) + Anagrams.Of("AB")[0], 
                           s.Substring(2,1) + Anagrams.Of("AB")[1]
                       };

Hang on, we still have literal values on all 6 lines. Are we making any progress at all? or are we just moving the problem around? We have made progress. We’ve actually eliminated half the literals. Now we’re almost in a position to remove those literals completely. Remember the original string ‘s’ has a value of “ABC”, so to get the “BC” of the first two lines, we need to drop the first character (“A”) from “ABC”.

Time to do a little more TDDing, let’s pretend we have the function we need.

            return new List<string>
                       {
                           s.Substring(0,1) + Anagrams.Of(DropCharacter(s,0))[0], 
                           s.Substring(0,1) + Anagrams.Of(DropCharacter(s,0))[1], 
                           s.Substring(1,1) + Anagrams.Of("AC")[0], 
                           s.Substring(1,1) + Anagrams.Of("AC")[1], 
                           s.Substring(2,1) + Anagrams.Of("AB")[0], 
                           s.Substring(2,1) + Anagrams.Of("AB")[1]
                       };

This won’t compile, we don’t have the DropCharacter function. Let’s get the test passing in the simplest possible way.

        private static string DropCharacter(string s, int index)
        {
            return "BC";
        }

Strictly speaking I’ve skipped a step there. What I would actually do is create the function so that everything compiles, but have it return the wrong value, so that I have a failing test. Then by having the function return “BC” I get the test to Green. This reassures me that my tests are actually joined up to the code.

We’re still have literal value duplication between our tests and our code, but let’s get DropCharacter fully working before we tackle that. Right now it works if we want to drop the first character (“A”). Let’s try to expand it’s use.

            return new List<string>
                       {
                           s.Substring(0,1) + Anagrams.Of(DropCharacter(s,0))[0], 
                           s.Substring(0,1) + Anagrams.Of(DropCharacter(s,0))[1], 
                           s.Substring(1,1) + Anagrams.Of(DropCharacter(s,1))[0], 
                           s.Substring(1,1) + Anagrams.Of(DropCharacter(s,1))[1], 
                           s.Substring(2,1) + Anagrams.Of("AB")[0], 
                           s.Substring(2,1) + Anagrams.Of("AB")[1]
                       };

This will give us a failing test. The next failing test doesn’t always have to be a new test. We actually have all of the tests we need. What has happened here is that we’ve tried to make one part of our code more general, in doing so we’ve identified a hard coding issue elsewhere in the code. We are effectively test driving the ‘DropCharacter’ function by proxy. Our ‘Anagrams.Of’ function is using ‘DropCharacter’ in ways that it can’t handle.

You should know the drill for getting back to green by now, protect the working code with an ‘if’ and get the new test passing as simply as possible.

        private static string DropCharacter(string s, int index)
        {
            if(index == 0)
                return "BC";

            return "AC";
        }

Let’s sort out the final case for ‘DropCharacter’ and then see where we stand.

            return new List<string>
                       {
                           s.Substring(0,1) + Anagrams.Of(DropCharacter(s,0))[0], 
                           s.Substring(0,1) + Anagrams.Of(DropCharacter(s,0))[1], 
                           s.Substring(1,1) + Anagrams.Of(DropCharacter(s,1))[0], 
                           s.Substring(1,1) + Anagrams.Of(DropCharacter(s,1))[1], 
                           s.Substring(2,1) + Anagrams.Of(DropCharacter(s,2))[0], 
                           s.Substring(2,1) + Anagrams.Of(DropCharacter(s,2))[1]
                       };

To get this passing we’ll use another ‘if’

        private static string DropCharacter(string s, int index)
        {
            if(index == 0)
                return "BC";

            if(index == 1)
                return "AC";

            return "AB";
        }

Time for some refactoring now. We need to eliminate these literal values once and for all. Dropping the first and last characters is easy.

        private static string DropCharacter(string s, int index)
        {
            if(index == 0)
                return s.Substring(1,2);

            if(index == 1)
                return "AC";

            return s.Substring(0,2);
        }

Of course we’ve hard coded the parameters to Substring, which means we’re still tied to strings of three characters. One step at a time. Let’s sort out the case where we’re dropping the middle character, and then see if we can generalise for any string length.

            if(index == 1)
                return "A" + "C";

The letter “B” has been dropped, “A” and “C” represent the parts of the string before and after the dropped letter. So, we split the string and deal with each part seperately.

            if(index == 1)
                return s.Substring(0,1) + s.Substring(2,1);

Here’s where we stand.

        private static string DropCharacter(string s, int index)
        {
            if(index == 0)
                return s.Substring(1,2);

            if(index == 1)
                return s.Substring(0,1) + s.Substring(2,1);

            return s.Substring(0,2);
        }

We’ve eliminated the dependency on literal strings, but we’ve replaced it with a dependency on strings a of particular length. That’s progress of sorts. We have the string ‘s’ and the position of the dropped character ‘index’ to work with. We need to trace these hard coded values back to these two inputs. This can be a little tricky. Just because you know that index will have a value of 1 under certain circumstances, doesn’t mean that every instance of the value 1 can be replaced with index.

Let’s start with the portion of the string, before the dropped character. There are two places in the function where that piece of string is referred to, and by using the ‘index’ variable we can eliminate some of the hard coding of the number of characters.

        private static string DropCharacter(string s, int index)
        {
            if(index == 0)
                return s.Substring(1,2);

            if(index == 1)
                return s.Substring(0,index) + s.Substring(2,1);

            return s.Substring(0,index);
        }

We can introduce a ‘before’ variable that makes this explicit.

        private static string DropCharacter(string s, int index)
        {
            var before = s.Substring(0, index);

            if (index == 0)
                return s.Substring(1,2);

            if(index == 1)
                return before + s.Substring(2,1);

            return before;
        }

Now we need to deal with the portion of the string that comes after the dropped character. Again we have two examples of this in the code. We can see that the first parameter to Substring, the starting position of the substring seems to be ‘index + 1’. Let’s plug that in.

        private static string DropCharacter(string s, int index)
        {
            var before = s.Substring(0, index);

            if (index == 0)
                return s.Substring(index + 1, 2);

            if(index == 1)
                return before + s.Substring(index + 1, 1);

            return before;
        }

The second parameter to Substring isn’t quite so simple, it depends on both the index of the dropped character and the length of the original string. Nonetheless it’s reasonably easy to figure out.

        private static string DropCharacter(string s, int index)
        {
            var before = s.Substring(0, index);

            if (index == 0)
                return s.Substring(index + 1, s.Length - (index + 1));

            if(index == 1)
                return before + s.Substring(index + 1, s.Length - (index + 1));

            return before;
        }

For clarity, let’s introduce another variable to really make this all obvious.

        private static string DropCharacter(string s, int index)
        {
            var before = s.Substring(0, index);
            var after = s.Substring(index + 1, s.Length - (index+1));

            if (index == 0)
                return after;

            if(index == 1)
                return before + after;

            return before;
        }

And, we can simplify this, as follows

        private static string DropCharacter(string s, int index)
        {
            var before = s.Substring(0, index);
            var after = s.Substring(index + 1, s.Length - (index+1));

            return before + after;
        }

Our final task is to turn our attention back to the ‘Anagrams.Of’ function and sort it out.

        public static List<string> Of(string s)
        {
            if (s.Length <= 1)
                return new List<string> { s };

            if(s.Length == 2)
            {
                return new List<string>
                       {
                           s, 
                           s.Substring(1,1) + s.Substring(0,1)
                       };
            }

            return new List<string>
                       {
                           s.Substring(0,1) + Anagrams.Of(DropCharacter(s,0))[0], 
                           s.Substring(0,1) + Anagrams.Of(DropCharacter(s,0))[1], 
                           s.Substring(1,1) + Anagrams.Of(DropCharacter(s,1))[0], 
                           s.Substring(1,1) + Anagrams.Of(DropCharacter(s,1))[1], 
                           s.Substring(2,1) + Anagrams.Of(DropCharacter(s,2))[0], 
                           s.Substring(2,1) + Anagrams.Of(DropCharacter(s,2))[1]
                       };
        }

Those six lines of code that create the six anagrams of a three character word look promising. There’s a reasonably obvious loop happening there.

The first thing we need to do is get rid of the list initialiser code, so that we can add items to the list using a loop.

            var anagrams = new List<string>();
            anagrams.Add(s.Substring(0, 1) + Anagrams.Of(DropCharacter(s, 0))[0]);
            anagrams.Add(s.Substring(0, 1) + Anagrams.Of(DropCharacter(s, 0))[1]);
            anagrams.Add(s.Substring(1, 1) + Anagrams.Of(DropCharacter(s, 1))[0]);
            anagrams.Add(s.Substring(1, 1) + Anagrams.Of(DropCharacter(s, 1))[1]);
            anagrams.Add(s.Substring(2, 1) + Anagrams.Of(DropCharacter(s, 2))[0]);
            anagrams.Add(s.Substring(2, 1) + Anagrams.Of(DropCharacter(s, 2))[1]);
            return anagrams;

Now let’s get a loop working for us and delete some of this code.

            var anagrams = new List<string>();

            for (int i = 0; i < 3; i++ )
            {
                anagrams.Add(s.Substring(i, 1) + Anagrams.Of(DropCharacter(s, i))[0]);
                anagrams.Add(s.Substring(i, 1) + Anagrams.Of(DropCharacter(s, i))[1]);                
            }

            return anagrams;

We can nest another loop to reduce things even further

            for (int i = 0; i < 3; i++ )
                for (var j = 0; j < 2; j++)
                    anagrams.Add(s.Substring(i, 1) + Anagrams.Of(DropCharacter(s, i))[j]);

The upper bounds of both loop are hardcoded. Let’s get rid of those.

            for (int i = 0; i < s.Length; i++ )
                for (var j = 0; j < s.Length - 1; j++)
                    anagrams.Add(s.Substring(i, 1) + Anagrams.Of(DropCharacter(s, i))[j]);

It took a while to get here, but now we can tidy up the ‘Anagrams.Of’ function.

        public static List<string> Of(string s)
        {
            if (s.Length <= 1)
                return new List<string> { s };

            var anagrams = new List<string>();

            for (var i = 0; i < s.Length; i++ )
                for (var j = 0; j < s.Length - 1; j++)
                    anagrams.Add(s.Substring(i, 1) + Anagrams.Of(DropCharacter(s, i))[j]);

            return anagrams;
        }

And that’s it. Here’s the full listing of Tests and Code with a little bit of extra tweeking.

using System.Collections.Generic;
using NUnit.Framework;

namespace AnagramKata
{
    [TestFixture]
    public class AnagramTests
    {
        [Test]
        public void NoCharacters()
        {
            var expected = new List<string> { "" };
            Assert.That(Anagrams.Of(""), Is.EqualTo(expected));
        }

        [Test]
        public void OneCharacter()
        {
            var expected = new List<string> {"A"};
            Assert.That(Anagrams.Of("A"), Is.EqualTo(expected));
        }

        [Test]
        public void TwoCharacters()
        {
            var expected = new List<string> { "AB", "BA" };
            Assert.That(Anagrams.Of("AB"), Is.EqualTo(expected));
        }

        [Test]
        public void ThreeCharacters()
        {
            var expected = new List<string> { "ABC", "ACB", "BAC", "BCA", "CAB", "CBA" };
            Assert.That(Anagrams.Of("ABC"), Is.EqualTo(expected));
        }
    }

    public class Anagrams
    {
        public static List<string> Of(string s)
        {
            if (s.Length <= 1)
                return new List<string> { s };

            var anagrams = new List<string>();

            for (var i = 0; i < s.Length; i++ )
            {
                var root = s.Substring(i, 1);
                var rest = DropCharacter(s, i);
                for (var j = 0; j < s.Length - 1; j++)
                    anagrams.Add(root + Anagrams.Of(rest)[j]);
            }

            return anagrams;
        }

        private static string DropCharacter(string s, int index)
        {
            return s.Substring(0, index) + s.Substring(index + 1, s.Length - (index+1));
        }
    }
}

Snooker Kata

I’ve been toying with the following TDD Kata. I like it a lot, it provides just enough complexity that it’s interesting, but not so much that the algorithm needs to be complicated.

The idea is to implement a game of Snooker. I’ll assume you either know the rules of snooker, or can find them here.

We need a class that keeps track of a frame of snooker, including which player is at the table, which colour ball they should be targeting, and provides methods that allow us to tell the class what happens with each shot.

The Methods needed are

Hit(colour)
Pot(colour)
Miss(colour)
InOff(colour)
Nominate(colour)

We also need a number of methods that will give us back details about the state of the two players.

int Score(player)
int HighestBreak(player)
int Potted(player, colour)
  1. Implement Hit(Colour)
    Game will keep track of which player is at the table, and whether they should be hitting a red or another color. If the player hits any red when a red is expected, or any colour when a colour is expected, it shall be deemed a valid hit, and play shall switch to the other player.
  2. Wrong Ball Hit
    If a red is expected but a colour is hit, or vice versa, the game shall detect the foul and award the correct number of points to the other player and play shall switch to that player.
  3. Implement Pot(Colour)
    Same logic as above, however the appropriate number of points shall be awarded to the player at the table and play shall remain with that player.
  4. Implement Miss(Colour)
    This method indicates that the player at the table missed the targeted colour. Award the appropriate points to the opponent and switch player.
  5. Implement InOff(Colour)
    This method indicates that the player potted the cue ball while targeting a player of the suggested colour. Award the appropriate points to the opponent and switch player.
  6. Implement Nominate(Colour)
    This method should be used after the player has potted a red, it designates the desired colour that will be targeted. If Nominate is followed by Hit or Pot of a different colour, that is a foul. Award points to opponent and switch player. if Nominate is followed by Hit or Pot of the nominated colour that is valid, award points to the player and he remains at the table.
  7. Change Nominated Ball
    Allow the player to change nominated ball by simply calling Nominate again, the most recent call counts.
  8. Replace Potted Balls
    Colours are replaced on the table after being potted, reds stay off the table when potted.
  9. No Reds Left
    Detect when all reds have been potted, the players must then play for the lowest valued colour. They can not nominate a different colour. When colours are potted at this stage of the game they remain off the table.
  10. End Of Frame
    Play ends when the table is cleared.
  11. Statistics
    The following statistics should be available for each player at any time during or on completion of a frame:
    Score
    Highest Break
    Number of pots for each ball colour

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   |
|A|B|Op|Result?|
|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:

CalculatorDemo

!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   |
|A|B|Op|Result?|
|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.

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
        [Test()]
        public void Validation_CanPrevent_MoveNext()
        {
            Mock<IWizardStep> step1 = new Mock<IWizardStep>();
            step1.Setup(s => s.OKToMoveNext()).Returns(false);

            Wizard wizard = new Wizard()
                                    .AddStep(step1.Object)
                                    .Start();

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

            wizard.MoveNext();

            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
        [Test()]
        public void HM_Validation_CanPrevent_MoveNext()
        {
            IWizardStep step1 = new WizardStepThatIsNotOKToMoveNext();

            Wizard wizard = new Wizard()
                                    .AddStep(step1)
                                    .Start();

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

            wizard.MoveNext();

            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
        [Test()]
        public void step_can_stop_move_next()
        {
            IWizardStep step1 = new MockWizardStep()
                                    .ThatCannot.MoveNext
                                    .Object();

            Wizard wizard = new Wizard()
                                    .AddStep(step1)
                                    .Start();

            Assert.AreEqual(step1, wizard.CurrentStep);

            wizard.MoveNext();

            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()
                                    .ThatCan.MoveNext
                                    .Object();

            IWizardStep step1 = new MockWizardStep()
                                    .ThatCan.MoveNext
                                    .ThatCannot.MovePrevious
                                    .Object();

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
        {
            get
            {
                _thatCan = true;
                return this;
            }
        }

        public MockWizardStep ThatCannot
        {
            get
            {
                _thatCan = false;
                return this;
            }
        }


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

        public MockWizardStep MovePrevious
        {
            get
            {
                _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.