Machine.Specifications (MSpec)

The author of this BDD testing framework is Aaron Jensen of CodeBetter.com.  Probably the best introduction to the framework (and lightly touching on general principles of BDD) is Rob Conery’s post entitled Make BDD Your BFF.  MSpec is hosted on GitHub using the Git source control software (and here is the link for the repository again).  Download the code and build it to get the necessary libraries that you need into a Bin folder.  My MSpec libraries are a few months old, as I haven’t upgraded my source since my initial download back then.  I have not set up TestDriven.NET and am not sure it will be necessary for this simple coding exercise.  I am using NUnit for the actual testing framework underneath MSpec; the following article may be of interest to you if you would like to use a newer version of NUnit than what MSpec targets:

Using Latest NUnit Version with MSpec

MSpec helps you organize your code into Specifications, a core BDD concept.  It is inspired by early BDD testing frameworks like Ruby’s RSpec.  The syntax and arrangement can be a little odd for a static language like C#, but I think I like the direction it is heading.  Again, the best way to get familiar with the syntax, set up the MSpec Test Runner, and configure HTML reporting output is to read Rob’s introductory post on BDD and MSpec.

Setting Up the Visual Studio Solution

Let’s begin by creating a C# console application named AnagramCodeKata targeting .NET Framework 3.5.  The solution name (and solution folder) will be the same.  For our dependencies on MSpec (and NUnit), I have created a physical file system folder named Libraries and made it a sibling folder to the project’s physical folder (same level as the solution file).  That folder contains the following DLL libraries from the Bin folder of the compiled MSpec source code:

• CommandLine.dll
• Machine.Specifications.ConsoleRunner.exe
• Machine.Specifications.dll
• Machine.Specifications.NUnit.dll
• Machine.Specifications.Reporting.dll
• nunit.framework.dll

Then within our Solution Explorer, we only need to make references to 3 of these libraries (namely Machine.Specifications.dll, Machine.Specifications.NUnit.dll, and nunit.framework.dll).  I have also created two folders within our project in Solution Explorer, naming them Reports and Specifications.  The Reports folder will contain the HTML-generated report of running our tests every time.  The Specifications folder will hold our specifications and tests.  This is what our current Solution Explorer looks like now:

Also notice the MSpecRunner button at the top, which I’ve created to execute a custom External Tool that points to Machine.Specifications.ConsoleRunner.exe and passes in the appropriate parameters.  This helpful setup was put forth by Rob Conery in the link to his introductory blog post that I provided above.

Anagram Problem Statement

So let’s go ahead and look at the Anagram problem we are trying to solve.  Here’s a quick summary of what we are trying to accomplish:

“The challenge is fairly simple: given a file containing one word per line, print out all the combinations of words that are anagrams; each line in the output contains all the words from the input that are anagrams of each other.”

Unfortunately, Dave Thomas’ wordlist.txt link is broken on his blog post, and when responding to commenters asking for a fixed link to the text file, he pointed us all to some website that aggregates links to several word lists from around the Web.  Many of us readers wanted to know the exact word list file he used so that we could compare our results to his.  In his post, he states that there should be 2,530 sets of anagrams and 5,680 total words participating in those anagram sets.  The tough part about this is that we’ve got to have the same word list text file.  I searched the web and found a few, but I only found one that might be the same list.  It is from some guy’s personal GitHub repository:

http://github.com/krist0ff/code_kata/tree/ba975c3a64f11a81db2f3716b40de046f1ca7ef4/kata6

If you’re visiting this blog post, months or years after it was originally written, I obviously can’t guarantee this file will still be out there.  You can try emailing me or commenting here and I can hopefully send it to you via email if I still have it.  But more importantly, as we progress with this series, we’ll find out if it’s even the right word list or not.

Lastly, I’d like to look at the objectives for the coding kata that Dave Thomas outlines:

“Apart from having some fun with words, this kata should make you think somewhat about algorithms. The simplest algorithms to find all the anagram combinations may take inordinate amounts of time to do the job. Working though alternatives should help bring the time down by orders of magnitude. To give you a possible point of comparison, I hacked a solution together in 25 lines of Ruby. It runs on the word list from my web site in 1.5s on a 1GHz PPC. It’s also an interesting exercise in testing: can you write unit tests to verify that your code is working correctly before setting it to work on the full dictionary.”

I don’t think we’ll focus on runtime as much, but we’ll certainly revisit our algorithm as necessary if we have unacceptable wait times for the code to finish.  To complete this section, let’s go ahead and add the wordlist.txt to our solution at the root of of our Project node.

How About Some Actual Code?!

So let’s now start off by creating our first specification.  I have created a new C# file named AnagramsFinderSpecs.cs under our Specifications folder in our solution.  I attempted to write our first test, but already feel like I’m not inline with “favoring test driving logic over just testing data.”

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

using Machine.Specifications;

namespace AnagramCodeKata.Specifications
{
    [Subject(typeof(AnagramsFinder), "Finding Anagrams")]
    public class when_given_text_file_with_word_on_each_line
    {
        static int result;
        static AnagramsFinder sut;

        Establish context = () =>
        {
            sut = new AnagramsFinder();
        };

        Because of = () =>
        {
            result = sut.ParseTextFile("wordslist.txt");
        };

        It should_result_in_count_of_2530_anagram_sets = () =>
        {
            result.ShouldEqual(2530);
        };
    }
}

If you can’t make out the funky structure and syntax, again refer back to Rob Conery’s introductory post to all of this stuff that I link to at the top.  He does a great job of explaining what’s going on here.

Also, please remember that I have no clue what I’m doing and I’m just trying to copy people who know what they are doing.  I am hoping that I’ll be corrected by those who have a better idea of how to approach all of this.  This is a good stopping point because of my desire for feedback and the feeling of uncertainty I’m already getting.

Seriously, please guide me in the right direction or validate where I’m headed, because even I’m not sure where that is yet.  I will say this, I’m pretty sure I shouldn’t be reading in wordslist.txt yet, and that this might be where I need to start using a mocking framework.

Stay tuned, there’s more to come.  I just can’t tell what it will be about yet.  It’ll still be fun though, I promise.