Design contradictions between test levels

I thought I'd spend tonight finishing off the BDD Chessboard Kata exercise I started with Jim McDonald at an XP Manchester coding dojo. Jim is a fan of emergent design, whereas I advocate a little design up front.
For those who don't know the kata. There are a number of predefined specifications written in the Gherkin DSL based around the movement of 2 chess pieces on a chessboard.
This is the feature we were implementing.

Feature: Boundaries of the board.
In order to obey the rules of Chess
As a player
I want to be prevented from entering moves outside the boundary of the board.

Scenario: Pawn at top.
Given I have a White Pawn at A8
And I have a Black Knight at A1
When I move the Pawn to A9
Then I should be warned of an illegal move message

Scenario: Knight heads off board
Given I have a Black Knight at G8
And I have a White Pawn at A1
And I move the Pawn to A2
When I move the Knight to I7
Then I should be warned of an illegal move message

We've completed most of the steps on each of the scenarios using a location class implementing

    public interface ILocation

    {

        void MoveTo(string location);

    }

Each time we touched a class we've covered it with mspec tests.

    [Subject(typeof(Location))]

    public class When_creating_a_location_with_an_invalid_position

    {

        Because of = () =>; exception = Catch.Exception(() =>; new Location("Z22"));

        Behaves_like<AnInvalidLocation>; its_in_the_wrong_location;

        protected static Exception exception;

    }

    [Subject(typeof(Location))]

    public class When_moving_a_piece_to_invalid_location

    {

        Establish that = () =>; location = new Location("A1");

        Because of = () =>; exception = Catch.Exception( ()=>; location.MoveTo("X2"));

        Behaves_like<AnInvalidLocation> an_invalid_move; 

        protected static Exception exception;

        static ILocation location;

    }

I've DRYed out (a little) the invalid move behaviour in my Location.

Now that I've come to implement my final step, "Then I should be warned of an illegal move message".
I suddenly need to implement the invalid move behaviour. (Even though the WHEN is where the invalid move occurs I don't need to write the behaviour yet).

So this is where the emergent design has lead me to. If I am to follow the YAGNI or LRM principles I don't want do anything thing more than display a message. But If I change the behaviour of my location classes' MoveTo method to return a message, then the good design principles that my class level specifications has lead me too are at odds with the demands of the specification passing.

I am trying not to introduce another class to handle game messaging but by not doing so I undo my hard work at the class level. Is this the last responsible moment?

Thoughts on Xp Manchester BDD session

Last week I ran a session on BDD at XP Manchester. I'm writing up some notes on it so I thought I'd share them with the wider world.

A lot of the reading I've done on BDD has mainly focused on the tooling. This to a certain extent is unsurprising as inception of BDD was about getting people out of the 'test' mindset.  But as Dan North say's "Don't lose sight of the bigger picture or you'll miss all the good stuff". What is the bigger picture? Well that's a good question. Even though there is a wikipedia entry (more on this later), and a seemingly abandoned wiki driven website  it isn't completely clear what exactly BDD is. I thought that without a clear definition that it would be a useful exercise to find out what other practitioners thought.

Cue the XP Manchester session. I opened up with a very brief summary of what I thought people knew about BDD, the emphasis was on the tooling. (For the latecomers those were those magical 2 minutes).
Following the brief synopsis I wanted people's definitions of BDD. I got the group to write in brief their thoughts.

Attributes of BDD

In case you can't read my scrawl, the board read:

• It helps requirements
• It is automating acceptance criteria
• It is about communication
• It is a DSL
• It is a process
• It is a specification
• It is a pull based system approach
• It links features and functionality

The group seemed to focus on the automated acceptance testing side of it. Even though BDD as a process was mentioned the majority of the group seemed to lean towards BDD as an acceptance framework.

What I wanted to do was for the group to define BDD, the methodology. 

In doing the research for the session, I asked a question on the BDD google group. Its a good thread, well worth a read. Liz Keogh pointed me in the direction of a BDD definition (which can be found on wikipedia).

BDD is a second-generation, outside-in, pull-based, multiple-stakeholder, multiple-scale, high-automation, agile methodology. It describes a cycle of interactions with well-defined outputs, resulting in the delivery of working, tested software that matters.  

Discussion on definition

There's a lot in that. We spent the most of the rest of the session discussing the different parts of those 2 sentences. The trouble with interactive sessions is that the discussion can drift in other directions or falter.  And this part of the session wasn't quite how I'd imagined it would go. Because I had shown the group the definition the discussion lead down that path rather than creating something new.

So one the main discussion points were around Outside-in. The the group consensus is that we work from what the user wants, implement that from the UI afterwards. I touched on the analysis aspects of outside-in. That is when we do analysis on the domain, we start from what we know and then we delve down into the problem space until we have an adequate understanding. 

The other point which I feel which got some interest was that BDD encompasses all stakeholders. Not just the project sponsors, or the users but developers, infrastructure, everyone. We posticulated that this would throw up a lot more scenarios. Following on from this we discussed how that classes are microsystems, and that unit tests (or context specfications in our case) are just acceptance tests at a micro level.

Following the discussion. I wanted people to code so I devised a simple BDD exercise, supplying gherkin scenarios. I'm doing an MSc at the moment so I intend to analyse the results in my thesis.

If anybody fancies doing the exercise I'll post a follow-up blog on where it is and how you can help me.

Slides are below:

Exploring bdd

View more presentations from johnnonolan.