What’s wrong with plain tables?

Try this yourself: modify the expected scenario from the previous part to make it fail and re-run Cuke4Nuke. You’ll see that there’s something wrong, but what exactly? “Tables don’t match” isn’t the most helpful error message, especially when you’re dealing with a long list of objects.

Using scenario outlines

Luckily, Cucumber allows us to specify a scenario template and then a list of parameters for the template in a table. Instead of Scenario, we use the Scenario outline header. Parameters in the template should be enclosed in in the less-than < and greater-than > symbols. After the scenario, we list the examples in the table under the Examples header.

	Scenario Outline: Hello World (with examples)
		Given The Action is <action>
		When The Subject is <subject>
		Then The Greeting is <greeting>.

		Examples:
		|action|subject|greeting|
		|Hello|Mike|Hello, Mike|
		|Jump|Tom|Jump, Tom|
		|Shout|Jim|Shout, Jim|

Cucumber will execute the scenario once for each row of the Examples table. This is effectively the same as specifying the same scenario three times with different data, but a lot less verbose and easier to understand. As we’re using the same scenario steps as in part 1 of this tutorial, there is no new C# code and we can just run the whole thing again.

Try to break it again – modify one scenario example to fail. You’ll see a much better error report than with table arguments. The NUnit exception stack trace isn’t something I’d especially like to show to a business user, but Cuke4Nuke points us to the exact row and describes the failure in detail:

Scenario outlines allow us to re-run the same scenario steps several times for different parameter values, without special code to handle tables and with better error reporting. For further examples, see Richard Lawrence’s post on removing duplication using scenario outlines.

You can get the source code for all the examples mentioned in this tutorial from GitHub Cuke4NukeExample repository.

If you’re interested in learning more about Behaviour-Driven Development and Cucumber, check out my new BDD workshops.

Basic Software

• If you don’t already have Ruby installed, install it using the new one-click Ruby Installer. You don’t have to know Ruby to write Cuke4Nuke tests, but you still need it to run Cucumber. Install the Ruby development kit as well. Alternatively use the old 1.86 installer which comes with the development kit.
• Add GemCutter.org to the list of Ruby Gem sources. Execute the following command from the command line:

  gem sources -a http://gemcutter.org/

• Install the Cuke4Nuke gem. Execute the following command from the command line:

  gem install cuke4nuke

• Install the Win32Console gem to get colour reports in the windows console window:

  gem install win32console

  You might also need WAC to work around console colour problems so download that Exe and put it somewhere on the disk.

• If you don’t already have NUnit, grab the latest version from NUnit.org. We’ll need this later as Cuke4Nuke uses NUnit assertions.

To verify that the system is set up, execute Cuke4Nuke from the command line. You should see a help screen with Cuke4Nuke options. If you see an error that the command Cuke4Nuke isn’t found, check if there is a Cuke4Nuke.bat executable in your Ruby bin folder (C:\Ruby\bin if you accepted the default installation options for Ruby), whether that folder is on your executable path and whether Cuke4Nuke gem exists in the gems folder (C:\Ruby\lib\ruby\gems\1.8\gems\cuke4nuke-0.3.0 on my system).

Project setup

Create a normal C# class library project and add a Features folder to it. This is where your Cucumber scenarios will go. Add a step_definitions subfolder to that and create a file called cucumber.wire, with the following content:

host: localhost
port: 3901

This tells Cucumber to connect to an external system on port 3901, the default port for Cuke4Nuke. Now let’s add a test scenario to make sure that everything is working correctly. Create a file called basic.feature in the Features folder, with the following content:

Feature: Hello World
	In order to ensure that my installation works
	As a Developer
	I want to run a quick Cuke4Nuke test

	Scenario: Hello World
		Given The Action is Hello
		When The Subject is World
		Then The Greeting is Hello, World.

At this point, your project structure should look as on the picture below:

Now let’s run Cuke4Nuke for the first time. Build the project, open the console, go to your project folder and run the following command:

Cuke4Nuke bin\debug\Cuke4NukeExample.dll -q

(replace the DLL path with your project output DLL). You should see the Cucumber output telling you that there is one scenario with three steps, all of which are undefined. If you do not see the colours, add the -c flag and pipe the output to WAC.exe, making the command similar to the following:

Cuke4Nuke bin\debug\Cuke4NukeExample.dll -q -c | d:\apps\wag.exe

In any case, the command result should be similar to one on the picture below:

Now let’s add the step definitions that help Cucumber talk to our project code. Create a C# class file (say Steps.cs) and paste the following code:

using System;
using System.Text;
using Cuke4Nuke.Framework;
using NUnit.Framework;
namespace Cuke4NukeExample
{
    public class HelloWorldSteps{
        private String action;
        private String subject;
        [Given("^The Action is ([A-z]*)$")]
        public void ActionIs(String action)
        {
            this.action = action;
        }
        [When("^The Subject is ([A-z]*)$")]
        public void SubjectIs(String subject)
        {
            this.subject = subject;
        }
        [Then(@"The Greeting is ([^\.]*).")]
        public void CheckGreeting(String greeting)
        {
            Assert.AreEqual(greeting, action + ", "+subject) ;
        }
     }
}

Add a reference to NUnit.Framework.dll (from your NUnit installation) and Cuke4Nuke.Framework.dll (you’ll find it in C:\Ruby\lib\ruby\gems\1.8\gems\cuke4nuke-0.3.0\dotnet\Cuke4Nuke.Framework.dll). Now build the project again, go to the console and re-run the Cuke4Nuke command. The output should now say that the steps passed.

When it runs the feature specification, Cuke4Nuke will look for methods marked with Given, When and Then attributes that match steps by regular expression. Any capture groups in the regular expression are passed to the method as arguments (they don’t have to be Strings, you can use other .NET types as well). So, for example, the line “When The Subject is World” matches the following method:

[When("^The Subject is ([A-z]*)$")]
public void SubjectIs(String subject)
{
     this.subject = subject;
}

Our simple script will set the subject and the action and then verify the greeting using the standard NUnit assertion Assert.AreEqual. Just to see it when it fails, modify the CheckGreeting method or feature source so that they don’t match and re-run Cuke4Nuke.

Of course, for a proper project this code would talk to our domain classes but let’s keep it simple.

Build integration

We can add Cuke4Nuke as a post-build step so that all the specifications get executed after every build. Open your project .csproj file and add this just above the closing tag:

<PropertyGroup>
<PostBuildEvent>cuke4nuke $(TargetPath) $(ProjectDir)features -q
 </PostBuildEvent>
</PropertyGroup>

You can now inspect the results of Cuke4Nuke in your output window every time a project is built.

Continuous Integration

To complete the project setup, let’s run Cucumber tests within a continuous integration environment and store test outputs next to project build results. I use TeamCity even for .NET projects, so I’ll use it in this tutorial as well. (Setting up TeamCity is outside the scope of this tutorial, but it is fairly easy to do. Grab it from jetbrains.com). TeamCity 5 should support Cucumber out of the box but I haven’t been able to make it work. Cucumber/ANT docs for TeamCity suggests that a few environment variables should do the trick for ANT/Java builds but this doesn’t work for Cuke4Nuke. The Cucumber Teamcity template uses a deprecated API and fails to build with the latest Cucumber version, and the only other blog post I found on TeamCity and Cucumber uses the same (broken) API. However, Cucumber can export a JUnit XML test report file, which is more than enough to get us nicely integrated with TeamCity (even with the previous versions). We’ll make Cucumber save the test results into the test subfolder of our project folder, and tell TeamCity to monitor that. First, let’s change the .csproj project file. Modify the PropertyGroup block you just added to the following:

  <PropertyGroup>
    <PostBuildEvent>cuke4nuke $(TargetPath) $(ProjectDir)features -q
     -f junit -o$(ProjectDir)test</PostBuildEvent>
    <PreBuildEvent>del $(ProjectDir)test\*.xml</PreBuildEvent>
  </PropertyGroup>

This will save test output in the JUnit format (-f junit) into the test subfolder of our project directory (-o$(ProjectDir)test). It will also delete any previous test results from that folder when the build starts. Now set up your TeamCity project as normal. On the Build Runner configuration screen, select “ANT Junit” in the “XML Report Processing” section and set the import path as test/*xml (if you are working without a version control system, this will probably have to be a full path to your project folder rather than a relative path):

Everything should now be set up. You should be able to run the TeamCity build and get the “Tests passed:1″ message in TeamCity.

That’s it. Now continue writing feature specifications and implementing them in nice little iterations. Good luck! If you’re interested in this topic, you might also be interested in my new BDD with Cucumber workshops.

• BDD in .NET with Cucumber part 2: Making scenarios easier to read with tables
• BDD in .NET with Cucumber part 3: Scenario outlines and tabular templates
• Download source code

What’s new in this version?

Since the book was originally released, both FitNesse and the .NET FIT test runner were improved significantly. All the examples in this book are now updated to be compatible with the latest releases of FitNesse (20091121) and FitSharp (1.4). I re-wrote parts that are no longer applicable to the new FitSharp test runner, especially around Cell Operators. In a classic example of self-inflicted scope creep, I also wrote a new chapter on using domain objects directly.

I also changed the tool used for assembling the book. Instead of Apache FOP, I used XEP which will hopefully make the layout a bit better. Fonts (especially the code font) were also changed to make the book easier to read.

What about the paperback

I will make the paperback available soon. At the moment, the second edition is only available online.

The event started with Phil Trelford talking about SI system units of measure and how they fit into F# programming – apparently from the next release this language will have static compile-time checking that you’re using metres, grams and units such as that correctly without requiring you to implement a special class only for that. Phil well earned the appluause from the crowd when he launched a lunar lander game developed entirely in F# based on units of measure, the first practical application in F# that I’ve seen.

Dylan Beattie again did a very interesting presentation, this time on web deployment with MSDeploy and Web Platform Installer, two new Microsoft’s tools for web deployment. He started by going through a list of problems that people typically experience when they want to try out an opensource .NET web tool: setting up the correct version of ASP.NET web platform, SQL server, dependencies, configuring web.config, machine settings and IIS. Dylan then showed the Web Plaform Installer Gallery, a very interesting solution that automates installation of popular applications – comparing it to the Apple iPhone AppStore. Web Plaform Installer Gallery has installation scripts for lots of popular web projects so you can just install them with a few clicks. Dylan then explained how MSDeploy and Web Platform Installer work together to provide this functinality and how teams can use them to automate in-house web site deployment and synchronising development, test and production servers deployments.

David Ross presented MPI.NET, a library that helps organise computing clusters for Fork/Join parallel calculations. MPI (Message Passing Interface) is a standard for message interchange and collaboration for distributed processing, and MPI.NET is a wrapper around the original C API that makes it easier to use and exposes a .NET interface. David talked about Fork/Join and Map reduce patterns and demonstrated how MPI.NET helps write those with very little code.

Alan Dean then talked about Openspace coding days, a community project that started in January as a spin-off of the Alt.NET UK conference intended to be more practical. Openspace coding days are organised without a pre-determined plan, where attendees vote for topics of interest and then participate in workshops on those topics. These workshops range from well established technologies and practices to collaborative learning of a completely new technology or tool.

Scott Cowan demonstrated Spark, a view engine that has the advantages of intellisense support, being able to generate HTML using a command line tool and being more readable than ASP.NET tags. Spark uses special HTML elements and attributes and should look much more familiar to people who know HTML than ASP.NET or NVelocity. One of the more interesting things in the demonstration for me was how loops and conditional logic can be attached to normal HTML elements, such as DIV, avoiding the introduction of custom tags.

I presented how Concordion.NET helps us implement acceptance tests in plain English. Concordion.NET is a port of Concordion acceptance testing framework, originally developed by David Peterson and converted to .NET by Jeffrey Cameron. It works on HTML files and uses special HTML attributes to mark inputs and expected outputs of acceptance tests, allowing us to write and manage tests in free-form HTML text. Concordion.NET integrates with Gallio and links HTML documents to domain code using MBUnit-like fixtures. You can download the slides from resources.

The event ended in what is almost becoming a tradition, Sebastien Lambla presenting his Openrasta web framework (and working on the code to present until 10 minutes before his talk). Openrasta started as a REST framework which Sebastien presented at the first exchange, then became a MVC framework (implemented probably during the second exchange) and yesterday Sebastien demonstrated using embedded pre-compilers for ASP.NET and a standalone service, along with a new view engine based on C# with full intellisense support, so I guess OpenRasta is becoming a web server now.

In retrospect, I really enjoyed catching up with lots of people and I look forward to the next exchange. Next time I should really remember to start drinking after my talk, not before, or arrange to go earlier in the schedule.