Plain Text Story Runner using RSpec

At work we have started looking at the use of automated accpetance tests to provide validation of our development efforts. There are quite a few tools out there that can help with this; FitNesse, RSpec, NSpec, Selenium, Watir and WatiN to name a few.

So far we have found most success with RSpec and Watir. RSpec allows us to create plain text stories and acceptance criteria and run these as part of our integration builds. The slight problem we have is that we are mainly a .NET shop so using Ruby poses a few problems with regards to experience and knowledge. Unfortunately NSpec [which incorporates NBehave] doesn’t currently have a plain text story runner. Anyway here’s how you go about setting up RSpec in three simple steps.

Step 1: Write your story and acceptance criteria and save in a plain text file

Step 2: Create the story interpreter

Step 3: Create the runner

So without further ado I’ll explain each step in detail:

miniSPA 2008

I’ll be attending this years miniSPA conference. It’s billed as a free sampler of the best sessions from the full on SPA held earlier this year. In case you are wondering SPA stands for Software Practice Advancement.

Inventive uses of NUnit #1

The first in a series of articles that describe how you can go about using a testing framework in an ‘interesting’ way. First up is the shopping list.

What could be easier than updating a line of code, recompiling and running the test suite whilst out shopping?

BBC Hackday – Mashed 08

This weekend the BBC have arranged a follow up event to last years hackday. Mashed 08 is taking place at Alexandra Palace in North London and looks like it will be great fun. Have a look at the schedule and here for a quick overview.

It is now all over. Have a look here to see how it all went.

TDT

We have been running coding dojos once a week after work for the last couple of months. They have proved a valuable learning resource and people have been attending even though we run them after work. They focus on one aspect of technology and past topics include implementing UML class diagrams, Ruby on Rails 101 and OO Principles.

One technique I have found valuable for running a session is to prepare a set of failing tests beforehand. I recently ran a dojo on LINQ and Lambdas. I started with a test for the simplest possible LINQ expression I could think of. I made the test pass [using the standard red, green, re-factor]. I then removed the code and stored it inside a Visual Studio Snippet for quick retrieval during the dojo. At dojo time, I gave a brief intro to LINQ and the project structure I provided. And then one by one talked through the tests and got the attendees to implement the code to make the test pass. This keeps people focused on a single problem and keeps scope down to the knowledge you wish to get across. The feedback I received post dojo was positive. I call this approach Test Driven Teaching [TDT] and I would definitely encourage you to try it if you are thinking of running your own dojo.

Consistency Is Key

I’m sure I am not the only one who puzzles over Microsoft’s naming conventions for C#. I understand the Pascal and camel casing rules, but what I don’t get is the exception made for two letter acronyms. I’m looking at creating a dictionary of my code so that I can start to see patterns and opportunities for re-use. To do this I need to be able to break up the name of a method or class into its constituent parts. Regular expressions seemed like a good way to go. It is fairly trivial to write a regex that matches the parts that make up a Pascal and camel cased identifier. What makes this tricky is the exception for short acronyms. Here is my attempt:

Regex splitName = new Regex(@”^I(?=(\p{Lu}{2})*(\p{Lu}\p{Ll}|$))|(^\p{Ll}+|\p{Lu}\p{Ll}+|\p{Lu}{2})”);

It breaks down like so: