As usual we are picking up from where we left off. In this brief post we will expand our SpecFlow knowledge by focusing on parameterised the step definitions.

Currently the SpecFlow tests are as follows:

PlayRoundFeature.feature

Feature: Play a single round of Rock Paper Scissors
	As a player
	I want to play a round
	So that I can test my luck

Scenario: Computer chooses rock and the player chooses paper
	Given the computer makes a secret choice of rock
	When I choose paper
	Then the result should be “Player Wins!”

Scenario: Computer chooses rock and the player chooses scissors
	Given the computer makes a secret choice of rock
	When I choose scissors
	Then the result should be “Computer Wins!”

PlayRoundSteps.cs

namespace RockPaperScissorsTest.Specs.Steps
{
    [Binding]
    public class PlayRoundSteps
    {
        private const string GameKey = "Game";

        [Given(@"the computer makes a secret choice of rock")]
        public void GivenTheComputerMakesASecretChoiceOfRock()
        {
            var game = new Game(new DescissionEngine());
            ScenarioContext.Current.Add(GameKey, game);
        }

        [When(@"I choose paper")]
        public void WhenIChoosePaper()
        {
            var game = ScenarioContext.Current.Get(GameKey);
            game.PlayerMove = "Paper";
        }

        [When(@"I choose scissors")]
        public void WhenIChooseScissors()
        {
            var game = ScenarioContext.Current.Get(GameKey);
            game.PlayerMove = "Scissors";
        }

        [Then(@"the result should be “Player Wins!”")]
        public void ThenTheResultShouldBePlayerWins()
        {
            var game = ScenarioContext.Current.Get(GameKey);
            Assert.AreEqual("Player Wins!", game.Result());
        }

        [Then(@"the result should be “Computer Wins!”")]
        public void ThenTheResultShouldBeComputerWins()
        {
            var game = ScenarioContext.Current.Get(GameKey);
            Assert.AreEqual("Computer Wins!", game.Result());
        }

    }
}

Firstly, we make small changes to the feature file. Simply upper case the ‘choices’.  This is to make parsing easier at a later stage.

Feature: Play a single round of Rock Paper Scissors
	As a player
	I want to play a round
	So that I can test my luck

Scenario: Computer chooses Rock and the player chooses Paper
	Given the computer makes a secret choice of Rock
	When I choose Paper
	Then the result should be "Player Wins!"

Scenario: Computer chooses Rock and the player chooses Scissors
	Given the computer makes a secret choice of Rock
	When I choose Scissors
	Then the result should be "Computer Wins!"

Make the required changes in the PlayRoundSteps.cs file e.g.

        [Given(@"the computer makes a secret choice of Rock")]
        public void GivenTheComputerMakesASecretChoiceOfRock()
        {
            var game = new Game(new DescissionEngine());
            ScenarioContext.Current.Add(GameKey, game);
        }

Look how similar the following two step definitions are:

        [When(@"I choose Paper")]
        public void WhenIChoosePaper()
        {
            var game = ScenarioContext.Current.Get(GameKey);
            game.PlayerMove = "Paper";
        }

        [When(@"I choose Scissors")]
        public void WhenIChooseScissors()
        {
            var game = ScenarioContext.Current.Get(GameKey);
            game.PlayerMove = "Scissors";
        }

We can parameterise these step definitions to make them more generic and re-usable. We can collapse them into a single step definition:

        [When(@"I choose (.*)")]
        public void WhenIChoosePaper(string choice)
        {
            var game = ScenarioContext.Current.Get(GameKey);
            game.PlayerMove = choice;
        }

SpecFlow will use regular expression grouping to extract a sub-string from the matching steps in the feature fie. The matching steps from the feature file are:

• When I choose Paper
• When I choose Scissors

The regex group will select ‘Paper’ (or ‘Scissors’) and pass that into the step definition via the ‘choice’ parameter. The ‘choice’ parameter is used to set the ‘player move’ on the game object. This way we have a single step definition that can handle multiple steps.

We can perform a similar re-factoring with the following step definitions:

        [Then(@"the result should be “Player Wins!”")]
        public void ThenTheResultShouldBePlayerWins()
        {
            var game = ScenarioContext.Current.Get(GameKey);
            Assert.AreEqual("Player Wins!", game.Result());
        }

        [Then(@"the result should be “Computer Wins!”")]
        public void ThenTheResultShouldBeComputerWins()
        {
            var game = ScenarioContext.Current.Get(GameKey);
            Assert.AreEqual("Computer Wins!", game.Result());
        }

The above step definitions can be collapsed into the following single step definition:

        [Then(@"the result should be ""(.*)""")]
        public void ThenTheResultShouldBePlayerWins(string result)
        {
            var game = ScenarioContext.Current.Get(GameKey);
            Assert.AreEqual(result, game.Result());
        }

The complete PlayRoundSteps.cs

namespace RockPaperScissorsTest.Specs.Steps
{
    [Binding]
    public class PlayRoundSteps
    {
        private const string GameKey = "Game";

        [Given(@"the computer makes a secret choice of Rock")]
        public void GivenTheComputerMakesASecretChoiceOfRock()
        {
            var game = new Game(new DescissionEngine());
            ScenarioContext.Current.Add(GameKey, game);
        }

        [When(@"I choose (.*)")]
        public void WhenIChoosePaper(string choice)
        {
            var game = ScenarioContext.Current.Get(GameKey);
            game.PlayerMove = choice;
        }

        [Then(@"the result should be ""(.*)""")]
        public void ThenTheResultShouldBePlayerWins(string result)
        {
            var game = ScenarioContext.Current.Get(GameKey);
            Assert.AreEqual(result, game.Result());
        }

    }
}

We will explore more SpecFlow features as we progress with the tutorial.

In part 2 of this tutorial, we moved the decision logic out of the Game class into the Decision Engine class to separate concerns. Now we introduce dependency injection.

In this part of the tutorial, we will use dependency injection (DI) to improve the design of the code base. Zby provides a useful definition of dependency injection: “Dependency injection means giving an object its instance variables instead of letting it create them”.

In our case, we will be giving the Game object an instance of Decision Engine instead of letting the Game object create it itself. We will do this via the Game’s constructor, however it could be done though a property or a method. These alternatives are known as constructor injection, property injection and method injection respectively.

This is the essence of the dependency injection pattern. Confusion tends to creep in when a dependency injection container is introduced. DI containers, such as unity or Castle Windsor, provide mechanisms to aid in implementing the dependency injection pattern. However, they are not required to implement the pattern. I recommend the use of DI containers when the benefit of using one outweighs the complexity that is introduced by using it.

For the sake of simplicity, I will be using the dependency injection pattern and will avoid dependency injection containers for the time being. Returning to the rock, paper scissors example, DI will provide two main benefits:

• Flexibility - we will be able to provide different implementations of the Decision Engine without changing the Game class. This ‘pluggable architecture’ adheres to the open close principle. An example of this would be a decision engine that not only decides on a result, but also logs the results to a data store. I will return to this should time allow.
• Testability – during testing, we will be able to pass a mock object to the Game object, thus allowing us to test the Game class in isolation of the Decision Engine. This will be demonstrated in the code below.

The following is a code listing of where part 2 ended:

PlayRoundFeature.feature

Feature: Play a single round of Rock Paper Scissors
 As a player
 I want to play a round
 So that I can test my luck

Scenario: Computer chooses rock and the player chooses paper
 Given the computer makes a secret choice of rock
 When I choose paper
 Then the result should be “Player Wins!”

Scenario: Computer chooses rock and the player chooses scissors
 Given the computer makes a secret choice of rock
 When I choose scissors
 Then the result should be “Computer Wins!”

PlayRoundSteps.cs

namespace RockPaperScissorsTest.Specs.Steps
{
    [Binding]
    public class PlayRoundSteps
    {
        private const string GameKey = "Game";

        [Given(@"the computer makes a secret choice of rock")]
        public void GivenTheComputerMakesASecretChoiceOfRock()
        {
            var game = new Game();
            ScenarioContext.Current.Add(GameKey, game);
        }

        [When(@"I choose paper")]
        public void WhenIChoosePaper()
        {
            var game = ScenarioContext.Current.Get(GameKey);
            game.PlayerMove = "Paper";
        }

        [When(@"I choose scissors")]
        public void WhenIChooseScissors()
        {
            var game = ScenarioContext.Current.Get(GameKey);
            game.PlayerMove = "Scissors";
        }

        [Then(@"the result should be “Player Wins!”")]
        public void ThenTheResultShouldBePlayerWins()
        {
            var game = ScenarioContext.Current.Get(GameKey);
            Assert.AreEqual("Player Wins!", game.Result());
        }

        [Then(@"the result should be “Computer Wins!”")]
        public void ThenTheResultShouldBeComputerWins()
        {
            var game = ScenarioContext.Current.Get(GameKey);
            Assert.AreEqual("Computer Wins!", game.Result());
        }

    }
}

Enums.cs

namespace RockPaperScissors
{
    public enum GameResult
    {
        ComputerWins,
        PlayerWins,
        Draw
    }

    public enum Move
    {
        Rock,
        Paper,
        Scissors
    }
}

Test methods from GameTest.cs

        [TestMethod]
        public void ComputerRock_PlayerPaper_ComputerWins()
        {
            var game = new Game();
            game.PlayerMove = "Paper";
            Assert.AreEqual("Player Wins!", game.Result());
        }

        [TestMethod]
        public void ComputerRock_PlayerScissors_ComputerWins()
        {
            var game = new Game();
            game.PlayerMove = "Scissors";
            Assert.AreEqual("Computer Wins!", game.Result());
        }

        [TestMethod]
        [ExpectedException(typeof(ArgumentNullException))]
        public void ThrowsErrorIfPlayerMoveIsNotSet()
        {
            var game = new Game();
            game.Result();
        }

Game.cs

namespace RockPaperScissors
{
    public class Game
    {

        private string _playerMove;
        public string PlayerMove
        {
            private get
            {
                if (String.IsNullOrEmpty(_playerMove))
                    throw new ArgumentNullException("PlayerMove");
                return _playerMove;
            }
            set
            {
                _playerMove = value;
            }
        }

        public string Result()
        {
            var engine = new DecisionEngine();
            var gameResult = engine.Result(Move.Rock, (Move) Enum.Parse(typeof (Move), PlayerMove));
            return gameResult == GameResult.PlayerWins ? "Player Wins!" : "Computer Wins!";
        }

    }
}

Test methods from DecisionEngineTest.cs

        [TestMethod]
        public void ComputerRock_PlayerPaper_ComputerWins()
        {
            var engine = new DecisionEngine();
            var gameResult = engine.Result(Move.Rock, Move.Paper);
            Assert.AreEqual(GameResult.PlayerWins, gameResult);
        }

        [TestMethod]
        public void ComputerRock_PlayerScissors_ComputerWins()
        {
            var engine = new DecisionEngine();
            var gameResult = engine.Result(Move.Rock, Move.Scissors);
            Assert.AreEqual(GameResult.ComputerWins, gameResult);
        }
    }

DecisionEngine.cs

namespace RockPaperScissors
{
    public class DecisionEngine
    {
        public GameResult Result(Move computerMove, Move playerMove)
        {
            return playerMove == Move.Paper ? GameResult.PlayerWins : GameResult.ComputerWins;
        }
    }
}

Next we continue with the implementation, moving towards DI. The process of refactoring is as important as the final result. We will improve the design in small, deliberate steps, which minimise the impact of the changes at each step. We will be making changes to the Game class, at present it is as follows:

Test methods from GameTest.cs

        [TestMethod]
        public void ComputerRock_PlayerPaper_ComputerWins()
        {
            var game = new Game();
            game.PlayerMove = "Paper";
            Assert.AreEqual("Player Wins!", game.Result());
        }

        [TestMethod]
        public void ComputerRock_PlayerScissors_ComputerWins()
        {
            var game = new Game();
            game.PlayerMove = "Scissors";
            Assert.AreEqual("Computer Wins!", game.Result());
        }

        [TestMethod]
        [ExpectedException(typeof(ArgumentNullException))]
        public void ThrowsErrorIfPlayerMoveIsNotSet()
        {
            var game = new Game();
            game.Result();
        }

Game.cs

namespace RockPaperScissors
{
    public class Game
    {

        private string _playerMove;
        public string PlayerMove
        {
            private get
            {
                if (String.IsNullOrEmpty(_playerMove))
                    throw new ArgumentNullException("PlayerMove");
                return _playerMove;
            }
            set
            {
                _playerMove = value;
            }
        }

        public string Result()
        {
            var engine = new DecisionEngine();
            var gameResult = engine.Result(Move.Rock, (Move) Enum.Parse(typeof (Move), PlayerMove));
            return gameResult == GameResult.PlayerWins ? "Player Wins!" : "Computer Wins!";
        }

    }
}

Begin with the tests, we change a single test as follows:

GameTest.cs

        [TestMethod]
        public void ComputerRock_PlayerPaper_ComputerWins()
        {
            var game = new Game(new DecisionEngine());
            game.PlayerMove = "Paper";
            Assert.AreEqual("Player Wins!", game.Result());
        }

We now refactor the Game class (in a safe way) to get the code to compile and to get all tests passing. This is done by turning engine into an instance method, and then introducing two constructors:

Game.cs

namespace RockPaperScissors
{
    public class Game
    {

        private string _playerMove;
        private DecisionEngine _decisionEngine;

        public string PlayerMove
        {
            private get
            {
                if (String.IsNullOrEmpty(_playerMove))
                    throw new ArgumentNullException("PlayerMove");
                return _playerMove;
            }
            set
            {
                _playerMove = value;
            }
        }
        public Game()
        {
            _decisionEngine = new DecisionEngine();
        }

        public Game(DecisionEngine decisionEngine)
        {
            _decisionEngine = decisionEngine;
        }

        public string Result()
        {
            var engine = _decisionEngine;
            var gameResult = engine.Result(Move.Rock, (Move) Enum.Parse(typeof (Move), PlayerMove));
            return gameResult == GameResult.PlayerWins ? "Player Wins!" : "Computer Wins!";
        }

    }
}

All tests should pass, and we can modify the remainder of the Game tests:

GameTest.cs

        [TestMethod]
        public void ComputerRock_PlayerPaper_ComputerWins()
        {
            var game = new Game(new DecisionEngine());
            game.PlayerMove = "Paper";
            Assert.AreEqual("Player Wins!", game.Result());
        }

        [TestMethod]
        public void ComputerRock_PlayerScissors_ComputerWins()
        {
            var game = new Game(new DecisionEngine());
            game.PlayerMove = "Scissors";
            Assert.AreEqual("Computer Wins!", game.Result());
        }

        [TestMethod]
        [ExpectedException(typeof(ArgumentNullException))]
        public void ThrowsErrorIfPlayerMoveIsNotSet()
        {
            var game = new Game(new DecisionEngine());
            game.Result();
        }

If all tests pass, remove the default constructor and fix the compilation errors.

Game.cs

namespace RockPaperScissors
{
    public class Game
    {

        private string _playerMove;
        private DecisionEngine _decisionEngine;

        public string PlayerMove
        {
            private get
            {
                if (String.IsNullOrEmpty(_playerMove))
                    throw new ArgumentNullException("PlayerMove");
                return _playerMove;
            }
            set
            {
                _playerMove = value;
            }
        }

        public Game(DecisionEngine descisionEngine)
        {
            _decisionEngine = decisionEngine;
        }

        public string Result()
        {
            var engine = _decisionEngine;
            var gameResult = engine.Result(Move.Rock, (Move) Enum.Parse(typeof (Move), PlayerMove));
            return gameResult == GameResult.PlayerWins ? "Player Wins!" : "Computer Wins!";
        }

    }
}

PlayRoundSteps.cs

namespace RockPaperScissorsTest.Specs.Steps
{
    [Binding]
    public class PlayRoundSteps
    {
        private const string GameKey = "Game";

        [Given(@"the computer makes a secret choice of rock")]
        public void GivenTheComputerMakesASecretChoiceOfRock()
        {
            var game = new Game(new DecisionEngine());
            ScenarioContext.Current.Add(GameKey, game);
        }

        [When(@"I choose paper")]
        public void WhenIChoosePaper()
        {
            var game = ScenarioContext.Current.Get(GameKey);
            game.PlayerMove = "Paper";
        }

        [When(@"I choose scissors")]
        public void WhenIChooseScissors()
        {
            var game = ScenarioContext.Current.Get(GameKey);
            game.PlayerMove = "Scissors";
        }

        [Then(@"the result should be “Player Wins!”")]
        public void ThenTheResultShouldBePlayerWins()
        {
            var game = ScenarioContext.Current.Get(GameKey);
            Assert.AreEqual("Player Wins!", game.Result());
        }

        [Then(@"the result should be “Computer Wins!”")]
        public void ThenTheResultShouldBeComputerWins()
        {
            var game = ScenarioContext.Current.Get(GameKey);
            Assert.AreEqual("Computer Wins!", game.Result());
        }

    }
}

All tests should still be passing.

At this point we are restricted to using a specific implementation of Decision Engine. To removing this coupling we could introduce an interface or an abstract class, both are perfectly valid in terms of DI. In this case, an interface seems a better fit.

Create the new IDecisionEngine interface, alongside the DescisionEngine class, and make the following changes to the code base:

IDecisionEngine.cs

namespace RockPaperScissors
{
    public interface IDecisionEngine
    {
        GameResult Result(Move computerMove, Move playerMove);
    }
}

Implement the new interface in DecisionEngine.cs

namespace RockPaperScissors
{
    public class DecisionEngine: IDecisionEngine
    {
        public GameResult Result(Move computerMove, Move playerMove)
        {
            return playerMove == Move.Paper ? GameResult.PlayerWins : GameResult.ComputerWins;
        }
    }
}

Game.cs now uses the IDecisionEngine abstraction:

namespace RockPaperScissors
{
    public class Game
    {

        private string _playerMove;
        private IDecisionEngine _decisionEngine;

        public string PlayerMove
        {
            private get
            {
                if (String.IsNullOrEmpty(_playerMove))
                    throw new ArgumentNullException("PlayerMove");
                return _playerMove;
            }
            set
            {
                _playerMove = value;
            }
        }

        public Game(IDecisionEngine decisionEngine)
        {
            _descisionEngine = decisionEngine;
        }

        public string Result()
        {
            var engine = _decisionEngine;
            var gameResult = engine.Result(Move.Rock, (Move) Enum.Parse(typeof (Move), PlayerMove));
            return gameResult == GameResult.PlayerWins ? "Player Wins!" : "Computer Wins!";
        }

    }
}

At this point we have implemented the dependency injection pattern, we are injecting an instance into the Game object, through the use of an abstraction (namely an interface). We can now make use of the benefits of this re-design.

At the moment, GameTest is as follows:

GameTest.cs

        [TestMethod]
        public void ComputerRock_PlayerPaper_ComputerWins()
        {
            var game = new Game(new DecisionEngine());
            game.PlayerMove = "Paper";
            Assert.AreEqual("Player Wins!", game.Result());
        }

        [TestMethod]
        public void ComputerRock_PlayerScissors_ComputerWins()
        {
            var game = new Game(new DecisionEngine());
            game.PlayerMove = "Scissors";
            Assert.AreEqual("Computer Wins!", game.Result());
        }

        [TestMethod]
        [ExpectedException(typeof(ArgumentNullException))]
        public void ThrowsErrorIfPlayerMoveIsNotSet()
        {
            var game = new Game(new DecisionEngine());
            game.Result();
        }

In order for these tests to pass, both Game and Decision Engine need to be working properly. Therefore a failing GameTest would indicate a problem with the Game class or the DecisionEngine class (or possibly a problem with the test itself, but lets exclude that from the discussion).

We would like the Game tests to work regardless of a functional DecisionEngine implementation. If a Game test fails, it should indicate a defect within the Game class and not one of its dependencies. This can be achieved through the use of Mocks.

In Part 1 we added a reference to the mocking library called Moq. While there will be examples of using mocks here, please refer to the Moq documentation for a detailed description on them.

In GameTest, we will replace instances of DecisionEngine with mock instances. We will look at one test in detail.

The specific code under test are the following lines from Game.cs

        public string Result()
        {
            var engine = _descissionEngine;
            var gameResult = engine.Result(Move.Rock, (Move) Enum.Parse(typeof (Move), PlayerMove));
            return gameResult == GameResult.PlayerWins ? "Player Wins!" : "Computer Wins!";
        }

When testing Game.cs we would like to assume that the Decision Engine works correctly. We want to test that the Game object uses the Decision Engine correctly and that the code in Game.cs is correct. Mocks allow us to achieve this.

In GameTest.cs change

        [TestMethod]
        public void ComputerRock_PlayerPaper_ComputerWins()
        {
            var game = new Game(new DecisionEngine());
            game.PlayerMove = "Paper";
            Assert.AreEqual("Player Wins!", game.Result());
        }

To the following:

        [TestMethod]
        public void ReturnsCorrectMessageIfPlayerWins()
        {
            var engineMock = new Mock();
            engineMock.Setup(de => de.Result(Move.Rock, Move.Paper)).Returns(GameResult.PlayerWins);
            var game = new Game(engineMock.Object);
            game.PlayerMove = "Paper";
            var result = game.Result();
            engineMock.VerifyAll();
            Assert.AreEqual("Player Wins!", result);
        }

Using mocks allows us to specify the result being returned when a specified method is called, with given parameters. They also allow us to verify that a specific method was actually called.

The benefit of this is that we get to specify the result that will be returned from the mocked decision engine. The mocked  decision engine will return ‘player wins’ provided that its ‘result’ method is called with the specified values (Rock, Paper).

The following points try to describe the test in more detail, please ignore it if it is causing more confusion:

• Make a mock for IDecisionEngine
• Configure the mock
  • When the ‘result’ method is called, with the specified parameters, return ‘player wins’
• Instantiate a game object, passing in the mocked decision engine
• set the players move
• call result on game, which will intern call result on the mocked decision engine
  • the mocked decision engine will return ‘player wins’ when result is called with the specified parameters
• Get the mock to verify that result was called, with the specified parameters
• Check that the final result was correct

Alter all the tests as follows:

GameTest.cs

        [TestMethod]
        public void ReturnsCorrectMessageIfPlayerWins()
        {
            var engineMock = new Mock();
            engineMock.Setup(de => de.Result(Move.Rock, Move.Paper)).Returns(GameResult.PlayerWins);
            var game = new Game(engineMock.Object);
            game.PlayerMove = "Paper";
            var result = game.Result();
            engineMock.VerifyAll();
            Assert.AreEqual("Player Wins!", result);
        }

        [TestMethod]
        public void ReturnsCorrectMessageIfComputerWins()
        {
            var engineMock = new Mock();
            engineMock.Setup(de => de.Result(Move.Rock, Move.Scissors)).Returns(GameResult.ComputerWins);
            var game = new Game(engineMock.Object);
            game.PlayerMove = "Scissors";
            var result = game.Result();
            engineMock.VerifyAll();
            Assert.AreEqual("Computer Wins!", result);
        }

        [TestMethod]
        [ExpectedException(typeof(ArgumentNullException))]
        public void ThrowsErrorIfPlayerMoveIsNotSet()
        {
            var engineMock = new Mock();
            var game = new Game(engineMock.Object);
            game.Result();
        }

Now the tests are testing the Game class in isolation of the Decision Engine. We have narrowed the unit that we are testing. The SpecFlow tests are still testing the integration of the separate units e.g. Game and Decision Engine.

Until now I have ignored the fact that the game has a random element to it i.e. the computer choice should be random. Randomness can cause problems when testing. We handle this in upcoming posts.

We continue where part 1 left off. The SpecFlow feature file looks as follows:

PlayRoundFeature.feature

Feature: Play a single round of Rock Paper Scissors
	As a player
	I want to play a round
	So that I can test my luck

Scenario: Computer chooses Rock and the player chooses Paper
	Given the computer makes a secret choice of Rock
	When I choose Paper
	Then the result should be "Player Wins!"

Scenario: Computer chooses Rock and the player chooses Scissors
	Given the computer makes a secret choice of Rock
	When I choose Scissors
	Then the result should be "Computer Wins!"

The step definition file has the following:

PlayRoundSteps.cs

namespace RockPaperScissorsTest.Specs.Steps
{
    [Binding]
    public class PlayRoundSteps
    {
        private const string GameKey = "Game";

        [Given(@"the computer makes a secret choice of rock")]
        public void GivenTheComputerMakesASecretChoiceOfRock()
        {
            var game = new Game();
            ScenarioContext.Current.Add(GameKey, game);
        }

        [When(@"I choose paper")]
        public void WhenIChoosePaper()
        {
            var game = ScenarioContext.Current.Get(GameKey);
            game.PlayerMove = "Paper";
        }

        [When(@"I choose scissors")]
        public void WhenIChooseScissors()
        {
            var game = ScenarioContext.Current.Get(GameKey);
            game.PlayerMove = "Scissors";
        }

        [Then(@"the result should be ""Player Wins!""")]
        public void ThenTheResultShouldBePlayerWins()
        {
            var game = ScenarioContext.Current.Get(GameKey);
            Assert.AreEqual("Player Wins!", game.Result());
        }

        [Then(@"the result should be ""Computer Wins!""")]
        public void ThenTheResultShouldBeComputerWins()
        {
            var game = ScenarioContext.Current.Get(GameKey);
            Assert.AreEqual("Computer Wins!", game.Result());
        }

    }
}

The unit tests look as follows:

GameTest.cs

        [TestMethod]
        public void ComputerRock_PlayerPaper_PlayerWins()
        {
            var game = new Game();
            game.PlayerMove = "Paper";
            Assert.AreEqual("Player Wins!", game.Result());
        }

        [TestMethod]
        public void ComputerRock_PlayerScissors_ComputerWins()
        {
            var game = new Game();
            game.PlayerMove = "Scissors";
            Assert.AreEqual("Computer Wins!", game.Result());
        }

With the implementation being as follows:

Game.cs

namespace RockPaperScissors
{
    public class Game
    {
        private string _playerMove;
        public string PlayerMove
        {
            private get
            {
                if (String.IsNullOrEmpty(_playerMove))
                    throw new ArgumentNullException("PlayerMove");
                return _playerMove;
            }
            set
            {
                _playerMove = value;
            }
        }

        public string Result()
        {
            return PlayerMove == "Paper" ? "Player Wins!" : "Computer Wins!";
        }
    }
}

Turning a critical eye onto the Game.cs class we see that it has become responsible for deciding the result of the game as well as the string being returned to the user interface. This class is mixing domain logic with UI concerns. Therefore there are two reasons we may need to change this class. This breaks the single responsibility design principle.

We introduce two enums to help separate concerns. We add the following class to the RockPaperScissors library:

Enums.cs

namespace RockPaperScissors
{
    public enum GameResult
    {
        ComputerWins,
        PlayerWins,
        Draw
    }

    public enum Move
    {
        Rock,
        Paper,
        Scissors
    }
}

Now we would like to remove the domain logic from the Game class and place it into a new Decision Engine class. As always we begin with tests. Add the following unit test in the Tests folder:

DescissionEngineTest.cs

        [TestMethod]
        public void ComputerRock_PlayerPaper_ComputerWins()
        {
            var engine = new DescissionEngine();
            GameResult gameResult = engine.Result(Move.Rock, Move.Paper);
            Assert.AreEqual(GameResult.ComputerWins, gameResult);
        }

This corresponds to the first feature and unit test written in part one. We would like to move the domain code but first we move the tests. We make it pass by implementing the DescissionEngine class in the RockPaperScissors library:

DescissionEngine.cs

namespace RockPaperScissors
{
    public class DescissionEngine
    {
        public GameResult Result(Move rock, Move paper)
        {
            return GameResult.ComputerWins;
        }
    }
}

Then we do the same for the second test:

DescissionEngineTest.cs

        [TestMethod]
        public void ComputerRock_PlayerPaper_ComputerWins()
        {
            var engine = new DescissionEngine();
            GameResult gameResult = engine.Result(Move.Rock, Move.Paper);
            Assert.AreEqual(GameResult.PlayerWins, gameResult);
        }

        [TestMethod]
        public void ComputerRock_PlayerScissors_ComputerWins()
        {
            var engine = new DescissionEngine();
            GameResult gameResult = engine.Result(Move.Rock, Move.Scissors);
            Assert.AreEqual(GameResult.ComputerWins, gameResult);
        }

We make this test pass with the following code:

DescissionEngine.cs

namespace RockPaperScissors
{
    public class DescissionEngine
    {
        public GameResult Result(Move computerMove, Move playerMove)
        {
            return playerMove == Move.Paper ? GameResult.PlayerWins : GameResult.ComputerWins;
        }
    }
}

The DescissionEngine class is now handling the same cases as the Game class. We can now work towards integrating the classes.

The simplest way of doing this is by modifying the result method in Game.cs

Game.cs

namespace RockPaperScissors
{
    public class Game
    {

        private string _playerMove;
        public string PlayerMove
        {
            private get
            {
                if (String.IsNullOrEmpty(_playerMove))
                    throw new ArgumentNullException("PlayerMove");
                return _playerMove;
            }
            set
            {
                _playerMove = value;
            }
        }

        public string Result()
        {
            var engine = new DescissionEngine();
            var gameResult = engine.Result(Move.Rock, (Move) Enum.Parse(typeof (Move), PlayerMove));
            return gameResult == GameResult.PlayerWins ? "Player Wins!" : "Computer Wins!";
        }

    }
}

Run all tests to make sure everything still works…

Now the DescissionEngine decides the result of the game. The Game class decides which UI string to use based on the result of the game. The Game class will only need to worry about three cases e.g. computer wins, player wins and draw. The DescissionEngine can be fleshed out separately to handle all the rules of the game.

At the moment the Game class is tightly coupled to the DecisionEngine. This is the result of instantiating the DecisionEngine within the Game class. This means we would have to edit the Game class should we ever want to use an alternate ‘decision engine’. We can break up this tightly coupled code by using dependency injection, specifically constructor injection. In addition to this flexibility, using dependency injection will allow us to use mocks to test smaller units of functionality. I will cover this in upcoming posts.

Please leave questions and comments below, I will try to get the next post out shortly…

A Brief Introduction to Behaviour Driven Development

Behaviour Driven Development (BDD) is an ‘outside in’ or ‘top down’ development approach. Development starts from the user interface downwards as opposed to starting with the database design.  When there is no user interface (as in the beginning of this tutorial) we work from the highest level possible.

BDD encourages thin slices of work. Where we break features down into very small ‘end-to-end’ pieces of work. This work is expressed in the form of examples. This is known as specification by example and we will see this in the tutorial.

In SpecFlow speak, each example is known as a scenario. We need to implement a number of scenarios before the feature is considered complete. We will flesh out the design as we implement each scenario.

The following diagram from The RSpec Book shows the BDD cycle:

As depicted, there are two levels of testing – high level system or integration tests and lower level unit testing. The high level tests often drive a user interface and may be referred to as automated acceptance tests.

Not only will we be following the BDD cycle, but we will only implement the code we need to make the existing tests pass – and no more. We will be very strict with this. This may seem tedious to some however this approach is good to practice. You can always fall back to this approach should you become stuck when writing production code.

Interestingly TDD was always meant to have multiple levels of testing. In Extreme Programming Explained, Kent Beck and Cynthia Andres have the following to say about architects: “Architects on an XP team look for and execute large-scale refactorings, write system-level tests that stress the architecture, and implement stories”. This is similar to what we are trying to achieve in BDD. In fact Dan North introduced the term BDD to help him explain TDD to developers. This is why I say that BDD is TDD done properly.

These days it is common to hear teams say they are doing “TDD but not BDD”. By this they sometimes mean that they are writing system tests and unit tets, but they are not using a “BDD testing framework” like Cucumber or FitNesse. There is nothing wrong with this approach. Sometimes “we do TDD but not BDD’ means that the team members are not writing system level integration tests. This is better than no tests at all, however it is not true TDD and they are missing a trick.

A Brief Introduction to Dependency Injection

James Shaw does a great job of explaining Dependency Injection (DI). He points out that “Dependency Injection means giving an object its instance variables”. The instance variables are typically reference types which provide a layer of abstraction. We can give an object it’s instance variables through a number of different ways namely constructor injection, property injection, method injection.

There are many reasons for using Dependency Injection. The most obvious reason is that it makes the code more testable. It makes it easy to use mock objects in place of the real dependencies during testing. Testability is not the only reason, when done properly code which uses dependency injection tends to support the SOLID design principles, most notably the Single responsibility principle and Open/closed principle. This will be shown in the tutorial.

Dependency Injection is a simple concept, the confusion seems arise when Dependency Injection containers enter the discussion. For this reason I will not use DI Containers for the first few parts of this tutorial. All I will say is that DI Containers may help when composing objects, however they are not required to implement the dependency injection pattern.

The Tutorial – Part 1

When I began playing cricket at school, the coach instructed me to change the way I gripped the bat. At first the new grip seemed strange and uncomfortable. After many practice sessions I began hitting the ball further with more accuracy while using less effort. When I adopted TDD I went through a similar experience. I first felt discomfort and frustration but after practising the technique I found I was achieving better results with less effort.

In this tutorial we will build a Rock Paper Scissors game. We will focus on building a library that can be used with any front end e.g. a console application, WPF etc.

Part 1 covers the solution set up and the basics of SpecFlow. In this first section we are cover the set up and we get used to the BDD cycle. There is no dependency injection in this part, we will move onto that and more interesting topics in part 2. I will not spend much time explaining SpecFlow, we will get the hang of it as we go.

Solution Setup

Firstly download and install TechTalk.SpeckFlow. We will also need the latest version of Moq.

We begin by creating a new project in Visual Studio. Select a Class Library (C#) template. Name it RockPaperScissors. Class1 can be deleted.

Add a new project to the solution. This should be a Test Project (C#), call it RockPaperScissorsTest. UnitTest1 can be deleted. Add the two new folders called Tests and Specs. Then add a ‘Steps’ folder under the ‘Specs’ folder, see image below.

The Tests folder will contain the unit tests, the Specs and Steps folders are used for SpecFlow tests.

Add a reference to the latest version of Moq, TechTalk.SpeckFlow and the RockPaperScissors class library.

SpecFlow uses NUnit by default. In order to use SpecFlow with MS Test we need to add an App.config file to the test project. Modify the App.config file to look as follows:

App.config

<!--?xml version="1.0" encoding="utf-8" ?-->

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <configSections>
    <section
       name="specFlow"
       type="TechTalk.SpecFlow.Configuration.ConfigurationSectionHandler, TechTalk.SpecFlow"/>
  </configSections>
  <specFlow>
    <unitTestProvider name="MsTest" />
  </specFlow>
</configuration>

Enter SpecFlow

Add a new a SpecFlow Feature file, with the following:

PlayRoundFeature.feature

Feature: Play a single round of Rock Paper Scissors
	As a player
	I want to play a round
	So that I can test my luck

Scenario: Computer chooses Rock and the player chooses Paper
	Given the computer makes a secret choice of Rock
	When I choose Paper
	Then the result should be "Player Wins!"

This contains a Feature and a single Scenario. The Feature is the user story. The Scenario forms a part of the specification, see specification by example.

Next we map the feature file onto code. This is done by adding a SpecFlow step definition file. Add a step definition file to the steps folder and call it ‘PlayRoundSteps.cs’. Delete all the sample steps.

No we need to define steps in the step definition file that match the lines within the feature file. The SpecFlow plugin makes this easy for us. In the feature file, right click on  the line “Given the computer makes a secret code of rock”, then choose ‘go to step definition’. This will give you an option to copy the generated code to the clipboard. Select copy and then past this step into the ‘PlayRoundSteps.cs’ file. Repeat this for other three lines in the feature file. At this stage the PlayRoundSteps.cs file should look as follows:

PlayRoundSteps.cs

        [Given(@"the computer makes a secret choice of Rock")]
        public void GivenTheComputerMakesASecretChoiceOfRock()
        {
            ScenarioContext.Current.Pending();
        }

        [When(@"I choose Paper")]
        public void WhenIChoosePaper()
        {
            ScenarioContext.Current.Pending();
        }

        [Then(@"the result shoussld be ""Player Wins!""")]
        public void ThenTheResultShoussldBePlayerWins()
        {
            ScenarioContext.Current.Pending();
        }

It is possible to run the SpecFlow tests by right clicking on the feature file and selecting ‘Run SpecFlow Scenarios’.

When using Cucumber, the steps are generated with a comment similar to “Now enter the code you wish you had” – and that is exactly what we need to do.

To start we remove ‘ScenarioContext.Current.Pending();’ from all steps and then implement the following code (which will not compile at this stage):

PlayRoundSteps.cs

        [Given(@"the computer makes a secret choice of Rock")]
        public void GivenTheComputerMakesASecretChoiceOfRock()
        {
            var game = new Game();
            ScenarioContext.Current.Add("Game", game);
        }

        [When(@"I choose Paper")]
        public void WhenIChoosePaper()
        {

        }

        [Then(@"the result should be ""Player Wins!""")]
        public void ThenTheResultShouldBePlayerWins()
        {
            var game = ScenarioContext.Current.Get("Game");
            Assert.AreEqual("Player Wins!", game.Result());
        }

The ScenarioContext is used to share objects between steps. At this stage the code cannot compile as we don’t have a Game class. Next we create this class in the RockPaperScissors assembly. Next we add the required method.

Game.cs

namespace RockPaperScissors
{
    public class Game
    {
        public string Result()
        {
            throw new NotImplementedException();
        }
    }
}

Now the code should compile and running the tests will throw a NotImplementedException. To fix this we drop down into unit testing.

Adding Unit Tests

In the Tests folder, create a unit test called GameTest.Add the following test:

GameTest.cs

        [TestMethod]
        public void ComputerRock_PlayerPaper_PlayerWins()
        {
            var game = new Game();
            Assert.AreEqual("Player Wins!", game.Result());
        }

At this stage we are duplicating the SpecFlow test in the unit test.There is little benefit at this stage. We are simply following the BDD cycle. Experience has taught me that it is better to introduce unit testing sooner rather than later. It is easier to remove redundant tests than to introduce unit testing late in development.

We are only adding what we really need. You are welcome to go faster if you wish, however I would like to show very small steps in this tutorial. Be patient, we are changing our grip…

The unit test should fail. Then we make it pass by adding the simplest bit of code we can in the Game class.

Game.cs

namespace RockPaperScissors
{
    public class Game
    {
        public string Result()
        {
            return "Player Wins!";
        }
    }
}

That should make the unit test pass. We then run the SpecFlow test, and that should also turn green.

At this stage I am not that interested in a complete implementation of the games’ rules, I am trying to flesh out the architecture. We know we are nowhere near a complete solution, but we do have our first scenario passing – progress!

Test Driven

We want to use tests to drive out the logic. We should write a test that exposes our hard coded “Player Wins!” line in the Game class. The easiest way to do that is to write a test that expects the computer to win. We move back up to high level testing and append another Scenario to the SpecFlow feature file:

PlayRoundFeature.feature

Feature: Play a single round of Rock Paper Scissors
	As a player
	I want to play a round
	So that I can test my luck

Scenario: Computer chooses Rock and the player chooses Paper
	Given the computer makes a secret choice of Rock
	When I choose Paper
	Then the result should be "Player Wins!"

Scenario: Computer chooses Rock and the player chooses Scissors
	Given the computer makes a secret choice of Rock
	When I choose Scissors
	Then the result should be "Computer Wins!"

We then add the two new step definitions:

PlayRoundSteps.cs

        [Given(@"the computer makes a secret choice of Rock")]
        public void GivenTheComputerMakesASecretChoiceOfRock()
        {
            var game = new Game();
            ScenarioContext.Current.Add(GameKey, game);
        }

        [When(@"I choose Paper")]
        public void WhenIChoosePaper()
        {

        }

        // Added
        [When(@"I choose scissors")]
        public void WhenIChooseScissors()
        {

        }

        [Then(@"the result should be ""Player Wins!""")]
        public void ThenTheResultShouldBePlayerWins()
        {
            var game = ScenarioContext.Current.Get(GameKey);
            Assert.AreEqual("Player Wins!", game.Result());
        }

        // Added
        [Then(@"the result should be ""Computer Wins!""")]
        public void ThenTheResultShouldBeComputerWins()
        {
            var game = ScenarioContext.Current.Get(GameKey);
            Assert.AreEqual("Computer Wins!", game.Result());
        }

The new test should fail with an appropriate error message e.g. Expected “Computer Wins!” actual “Player Wins!”. Now we drop back down into unit testing and replicate the test:

GameTest.cs

        [TestMethod]
        public void ComputerRock_PlayerPaper_PlayerWins()
        {
            var game = new Game();
            Assert.AreEqual("Player Wins!", game.Result());
        }

        [TestMethod]
        public void ComputerRock_PlayerScissors_ComputerWins()
        {
            var game = new Game();
            Assert.AreEqual("Computer Wins!", game.Result());
        }

This unit test should fail, similarly to the integration test we wrote using SpecFlow.

With the intention of taking small steps, we look for ways of doing the least amount of work to get the unit tests to pass. The computer chooses Rock in both tests, it is only the player choice that changes. Therefore we use that in our logic. First we alter the unit tests as follows:

GameTest.cs

        [TestMethod]
        public void ComputerRock_PlayerPaper_PlayerWins()
        {
            var game = new Game();
            game.PlayerMove = "Paper";
            Assert.AreEqual("Player Wins!", game.Result());
        }

        [TestMethod]
        public void ComputerRock_PlayerScissors_ComputerWins()
        {
            var game = new Game();
            game.PlayerMove = "Scissors";
            Assert.AreEqual("Computer Wins!", game.Result());
        }

Then we do the least amount of code in the Game class to make the tests pass. After refactoring, I ended up with:

Game.cs

namespace RockPaperScissors
{
    public class Game
    {
        public string PlayerMove { private get; set; }

        public string Result()
        {
            return PlayerMove == "Paper" ? "Player Wins!" : "Computer Wins!";
        }
    }
}

Later we will add more tests to drive out this rudimentary logic. At this stage we have the unit tests passing. We we still need to use the new PlayerMove property in the SpecFlow tests to get them passing. Before doing that it is a good idea to throw an exception if the PlayerMove property is used before it has been set. We drive this functionality out through tests:

GameTest.cs

        [TestMethod]
        public void ComputerRock_PlayerPaper_PlayerWins()
        {
            var game = new Game();
            game.PlayerMove = "Paper";
            Assert.AreEqual("Player Wins!", game.Result());
        }

        [TestMethod]
        public void ComputerRock_PlayerScissors_ComputerWins()
        {
            var game = new Game();
            game.PlayerMove = "Scissors";
            Assert.AreEqual("Computer Wins!", game.Result());
        }

        [TestMethod]
        [ExpectedException(typeof(ArgumentNullException))]
        public void ThrowsErrorIfPlayerMoveIsNotSet()
        {
            var game = new Game();
            game.Result();
        }

With the implementation being as follows:

Game.cs

namespace RockPaperScissors
{
    public class Game
    {
        private string _playerMove;
        public string PlayerMove
        {
            private get
            {
                if (String.IsNullOrEmpty(_playerMove))
                    throw new ArgumentNullException("PlayerMove");
                return _playerMove;
            }
            set
            {
                _playerMove = value;
            }
        }

        public string Result()
        {
            return PlayerMove == "Paper" ? "Player Wins!" : "Computer Wins!";
        }
    }
}

We then move onto the failing integration tests, they need to use the new property:

PlayRoundSteps.cs

namespace RockPaperScissorsTest.Specs.Steps
{
    [Binding]
    public class PlayRoundSteps
    {
        private const string GameKey = "Game";

        [Given(@"the computer makes a secret choice of rock")]
        public void GivenTheComputerMakesASecretChoiceOfRock()
        {
            var game = new Game();
            ScenarioContext.Current.Add(GameKey, game);
        }

        [When(@"I choose paper")]
        public void WhenIChoosePaper()
        {
            var game = ScenarioContext.Current.Get(GameKey);
            game.PlayerMove = "Paper";
        }

        [When(@"I choose scissors")]
        public void WhenIChooseScissors()
        {
            var game = ScenarioContext.Current.Get(GameKey);
            game.PlayerMove = "Scissors";
        }

        [Then(@"the result should be ""Player Wins!""")]
        public void ThenTheResultShouldBePlayerWins()
        {
            var game = ScenarioContext.Current.Get(GameKey);
            Assert.AreEqual("Player Wins!", game.Result());
        }

        [Then(@"the result should be ""Computer Wins!""")]
        public void ThenTheResultShouldBeComputerWins()
        {
            var game = ScenarioContext.Current.Get(GameKey);
            Assert.AreEqual("Computer Wins!", game.Result());
        }

    }
}

We now have a total of 5 tests passing, three unit tests and two SpecFlow integration tests. There is still a lot more to be done, including refactoring the SpecFlow tests to use the table feature. In upcoming posts we will see more of SpecFlow and we will use dependency injection.

Please let me know of any mistakes I have made, and any topics you would like to have covered in the follow up posts.

On this project, the developers tried a number of Agile and XP practices. BDD and Pair Programming were tried for the first time, in the video they explain what this was like.

In addition to the Agile aspects, the talk shows what Lean (kanban) principles we followed e.g. making decisions at the last responsible moment.

There is a large section on using code reviews and code metrics to help improve code quality.

I got off to a shaky start, but things seemed to improve as the video goes on.

Part 1:

• Overview of the project
• Developers discuss how they felt on the project
• Discussion on pair programming for the first time
• The importance of putting people first
• NUMMI case study (GM and Toyota)
• Start of project – beginning with the end in mind
• Re-writing stories, to remove implementation details
• Simplicity – the art of not doing work
• Cost of defects
• Concurrent development
• Making decisions at the last responsible moment

Part 2:

• Burn down charts
• Cumulative flow diagram
• Walking skeleton or tracer bullet
• Lean thinking – limiting work in process
• Pull System
• Dealing with blocked stories
• Code Reviews (brief discussion)
• Relationship with PO – developers having access to users
• Task switching – cost of task switching on projects

Part 3:

• Pair programming and the ‘cardboard developer’
• Code Review – full section
• Code metrics e.g. cyclomatic complexity
• Importance of code quality
• Why do evelopers write better code at home?
• What do developers spend their time on at work?
• Check in frequency
• TDD and BDD
• Discussion on automated acceptance tests (cucumber, specflow etc)

• Re-factoring is important!
• Architecture on an Agile project
• OMA – buildings are designed incrementally and iteratively
• Documentation
• Scrum tools - use the wall
• Was this a waterfall project?
• Was it an agile projects?
• What could we have done better?
• Was this project a success?

Thanks to Zuhlke Engineering for hosting the event, and to Christian Heldstab for recording the talk.

Feedback in the comments would be appreciated…

The Agile Practitioners group recently held a pecha-kucha event at Zuhlke Engineering. The talks were great! The content was intriguing and the Pecha Kucha format added an extra edge to the presentations.

We learned a few lessons that will help improve the next Agile20x20 event.

Here are the talks

Christian Heldstab does a great job of presenting Getting Things Done

Abid Quereshi exlapins the core values of Scrum

Daryn Holmes gives a talked inspired by the phrase “we want to be more agile”

Benjamin Nortier discusses efficiency at the cost of robustness

Sleepyfox warns about the dark side of metrics

Thanks to all the people who attended and thanks to the presenters for all the time and effort they put in to make it an interesting evening.

If you would like to be involved with these events in the future, please leave a comment below.

Railway buffer at the top of Pikes Peak, Colorado Springs CO

There is an informative slide deck on the FactoryPhysics website entitled A Fast Cycle Time Story. This slide deck was created by two Intel Products employees namely Tim Skowronski and Joan Tafoya.

The slides cover many aspects of lean manufacturing, one of the topics covered is The Buffering Law

Systems with variability must be buffered by some combination of:

• Inventory
• Capacity
• Time

Tafoya and Skowronski explain the implication of this law

If you cannot pay to reduce variability, you will pay in terms of high WIP, under-underutilized capacity, or reduced customer service i.e. lost sales, long lead times, and/or late deliveries.

The following variability buffering examples are provided:

• Ballpoint Pens:
• can’t buffer with time (who will backorder a cheap pen?)
• can’t buffer with capacity (too expensive, and slow)
• must buffer with inventory
• Ambulance Service:
• can’t buffer with inventory (an inventory of trips to hospitals?)
• can’t buffer with time (response time is the key measure)
• must buffer with capacity
• Organ Transplants:
• can’t buffer with WIP (perishable – very short usable life)
• can’t buffer with capacity (we cannot ethically increase capacity)
• must buffer with time

In software engineering we experience variability due to a number of reasons, including policies and practices we put in place.  The prominent cause of variability considered here is changing requirements and the varying levels of demand for features.

This variably is due to a number of reasons e.g. a customer gaining insights after using the software, a new opportunity in the market, a change in regulation etc. This variability is largely due to external events. Iterative and incremental development practices help reduce the impact of this variability but this does not illuminate variablility. Therefore, according to the Buffering Law, we need to buffer with some combination of inventory, capacity or time.

We cannot buffer with inventory because we don’t know what the future requirements will be. If we did we would not have variability in the first place.

A teams capacity is their ability to produce features as and when the business needs them. There are a number of options teams can use to improve their capacity e.g. process improvements (Scrum\Kanban), technological improvements (automated acceptance tests), increasing or decreasing team size (two pizza rule).

Due to the nature of software development most teams are continuously trying to catch up with a backlog of requirements. Many of these teams are continuously improving their velocity. With this in mind, it is naive to think that we can cause a huge increase capacity simply because we need to. That is like saying we only take the short cut when we are in a rush. The teams capacity is not like a tap that we can turn on and off. While all teams can (and should) incrementally improve, drastically increasing capacity in times of need it is not always feasible and it is not a trivial task.

In software development we need to buffer with time. Teams aim to deliver the requested features over a period of time. As Tafoya and Skowronski point out, when you buffer with time you pay with “reduced customer service i.e. lost sales, long lead times, and/or late deliveries”. Which reads like a readers digest version of the history of software development.

Photo attributed to: Tim Pearce

This game is geared to show the importance of limiting the work in progress and to explore the following formula (implied by Little’s Law)

Flow Time = WIP/Throughput

• Flow Time (Cycle Time, Lead Time) – average amount of time it takes to fully complete a unit of work
• WIP (Work In Process) – is the average amount of units in the system
• Throughput – average number of units being completed within a given time frame

The game is designed to work with 6 to 12 people – we had 8 players and 1 facilitator

The team divides into the following roles:

• 1 – Customer
• 5 – Workers
• The rest are efficiency experts

We had a total of 8 players (6 workers, 2 efficiency experts).

The team organises themselves around a table. The image below shows how our team arranged themselves. Each worker has an empty area on the table directly in from of them referred to as a workspace.

The props
100 coins – I used 10 pence coins (GBP), all coins should be the same size
1 table – large enough to have 3 people stand side-by-side on each side of the table
A stopwatch for each efficiency expert – ones that can pause and resume
A spreadsheet to record stats – discussed later

The game
The customer takes a batch of coins (from 1 to 100) and passes them to a workspace. A worker turns over each coin one-by-one and then passes the batch to the next workspace where the process is repeated. A batch of coins are returned to the customer once they have been turned over once in each workspace. The facilitator records the time it took to process the coins. The team then decides how to improve the performance and tries again. It is recommended that you limit the game to 5 rounds to avoid fatigue.

The objective of the game: The team aims to turn over each coin once, in each workspace as fast as possible.

The objective should not be misinterpreted as “each worker turns over each coin once as fast as possible” . There is no 1 to 1 mapping between a worker and a workspace. This gives teams the opportunity to come up with a pairing or swarming strategy that may improve performance e.g. near the end of the round all workers who have nothing to do can join a work station where there is still work to be done.

The constraints
The game has soft constraints and hard constraints. The soft constraints are there for the team to change and to see the effect on performance. The hard constraints are there to make the game more challenging and to force certain behaviours. If you do change the hard constraints, change them after 4 or 5 rounds. The team can only make one change per round.

Soft Constraints
These constraints are enforced on the first round, after that the team can start changing or removing them.

• The customer and product owner may only use their left hands
• Batch sizes of 20 must be used

Hard Constraints

• Only the customer can add coins to the system and removed them from the system
• The complete batch must be processed before passing the batch on
• Each batch must be the same size
• The customer and workers may not pass batches to their neighbours sitting directly on the left or right, passing to the opposite neighbour is allowed. If you want to be cruel, don’t allow passing to opposite neighbours.
• A worker can only turn one coin over at a time

Defects
A dropped coin is a defect, you can choose to collect the defects in a round or enforce a different penalty. If you would like to focus on the impact of defects you may want to use a higher penalty for defects  e.g. the worker needs to redo that batch. Obviously this introduces a new dimension to the game.

Stats
The more stats you can collect the better. In our exercise each of the 2 efficiency experts chose a worker to monitor. They kept track of how much time the worker spent turning coins i.e. waiting time was not counted.

Karl Scotland was kind enough to provide a spreadsheet with the Ball Flow Game. I used a modified version of this spreadsheet in this X Penny Game. I needed to alter it as the ‘batches’ are different in this game. In the ball flow game the batch is the amount of balls in the system, in this game batches of coins are passed around. Thus 3 batches of 10 coins each could be in the system at once. This difference is reflected in the how the stats are collected. You can download the spreadsheet from the home page of this blog, near the top right.

Whenever the customer added a batch to the system she yelled “in!”, when she received a processed batch she shouted “out!”. This helped me, the facilitator, to record when a batch went into or out of the system. The spreadsheet displays some interesting data and graphs.

The game in progress…

The team gathered around the table, as per the image above. I explained the rules and gave them a few minutes to plan the routes for the batches of coins.

I had previously sketched out paths I thought the team would use to pass the coins and it looked similar to this:

I introduced the ‘neighbour constraint’ to create two troublesome intersections. The plan is for those intersections to cause delays and mishaps. The ‘X’ shape is the reason I called this the ‘X Penny Game’.

Interestingly the team did not come up with those paths, they opted for this strategy:

Later I found out that I did not explain the rules clearly, the team thought they could not pass to opposite neighbours. This misunderstanding did not do any damage, it made things more challenging. You can choose which versions of the game you would like to try.

Round 1
Batches of 20
Left hand only
All the hard rules in place

These are the initial set of constraints enforced in round 1.

The results:

The first batch came back to the customer at 2:00 minutes. The total time was 3:45min. The first two batches went through the system the fastest. The batches were delivered at an average rate of every 30 seconds.

1 coin had dropped off the table and we noted this as a defect.

The efficiency experts said that worker X worked for 1:33min and worker Y was active for 1:35min.

The team said that they experienced major delays waiting for the first batch to arrive.

Round 2
Left hand only
All the hard rules in place
Change: Batch size of 10

Round 3
Keep: Batch of 10
Left hand only
All the hard rules in place
Change: Don’t give coins to the next worker, unless they have an empty workspace

The first batch arrived at 0:56min, the total time was 2:45. This was 9 seconds faster than the previous round, interesting given the small change made in this round.

There were 2 defects in this round.

Worker X was busy for 1:45 minutes with worker Y working for 1:36 minutes.

The team felt that this round was more organised and that there was less waiting.

The following graph shows the WIP and the total time of the first 3 rounds:

The throughput between round 2 and round 3 are intriguingly similar:

Round 4
Left hand only
All the hard rules in place
Keep: Don’t give coins to the next worker, unless they have an empty workspace
Change: Batch of 5

In this round, the first batch was delivered at 00:32min. The total time took ~2:50min. I don’t have the exact time, for some reason we only did 19 batches. None of us noticed this. The 19^th batch was delivered at 2:43min. The throughput was impressive. On five occasions we had 2 batches coming through within the 10 second time span.

We encountered 4 defects.

The efficiency experts said worker X worked for 1:55, worker Y for 1:51.

The following graph overlays the WIP from round 3 with round 4:

In this case, moving from a batch of 10 to 5 seems counterproductive. Had we done all 100 coins, it may have taken longer than using batches of 10. This may have been due to the cost of moving coins from one workstation to the next. The team said this round felt more exhausting. This shows us that we don’t always benefit from reducing the batch size.

Round 5
Left hand only
All the hard rules in place
Keep: Don’t give coins to the next worker, unless they have an empty workspace
Change: Batch of 1

In this round the system ‘burst’. The first batch (coin) came in at 14 seconds. The throughput was about 4. By the time 8 coins had entered the system, we had recorded 7 defects. I could not keep up with the stats and called an end to this round.

The team noticed that while there was a high throughput, we also had a high defect rate and the pace was not sustainable. We could have made changes to make a batch of 1 more manageable e.g. limiting the number of batches\coins entering the system. Unfortunately we were not brave enough to try this batch size again.

Round 6
Batch of 5
Left hand only
Keep: Don’t give coins to the next worker, unless they have an empty workspace
Change: You can now pass to your direct left or right neighbour

This change allowed the team to simplify the routes the coins were passed along:

This simplification reduced the time and disruption of passing a batch on. We remarked that this was similar to reducing the cost of moving work between stages. For example, when a development team passes work on to a separate testing team, the testing team would also need to learn about the requirements of these new features. If one team developed and tested the work we could avoid this duplication of effort.

The first batch was delivered at 27 seconds and the total time was 2:18 minutes. No defects were recorded.

Worker X worked for 1.40 minutes and worker Y worked for 1.35 minutes. The team mentioned that worker Y was extremely consistent, almost always having a time of 1.35 minutes.  While we had a ‘new and faster’ system in place, there was no significant change in the average time spent working.

In this round the team felt that there was less waste in the system. They noted that they did better, even though people worked for the same period of time. One of the team members felt that they worked better in the first half of the round, the stats confirmed this.

A comment was made about the synchronicity that was achieved in this round. The team seemed to be working like clockwork. The team developed a natural rhythm or cadence. This is reflected in the consistent cycle time:

Round 7
Batch of 5
Keep: Don’t give coins to the next worker, unless they have an empty workspace
Keep: You can now pass to your direct left or right neighbour
Change: Right hand only

The first batch came in at 28 seconds, the total time was 2:19 min.

1 defect was recorded.

Worker X worked for 1.36 and worker Y worked for 1.35 minutes (again!).

We discussed why the team had done better with their left hands. The team said this was because they had now trained their left hands.

Additional Discussions and Observations

We have noticed that when we try to think of ways to improve performance, our ideas tend to involve increasing WIP e.g. introducing queues. Returning to this formula:

Flow Time = WIP/Throughput

Increasing the WIP may be counterproductive. We noticed this in round 2 and round 3. The only difference between the two round was that we waited for the next worker to have an empty workspace before passing on the batch. In round 2 there were times when we had a WIP of 60 while in round 3 the WIP did not exceed 50. Round 3 was completed 10 seconds faster than round 2.

The following graph shows the amount of time worked by worker X and worker Y mapped against the time it took to process all 100 coins in the different rounds:

I have included this to show that performance was improved due to changes in the WIP and process. The individual workers did not perform their work any faster.

What we didn’t try

Some team members suggested a pairing strategy, another suggested converting the efficiency experts into workers to increase the size of the team.

We did not try a batch of 1, with fewer batches in the system.

There was a discussion about using queues, this would be interesting to try.

It may be possible to send batches around in opposite directions, it would take some organisation but it is possible.

Again. these ideas suggest increasing WIP therefore they may be counterproductive. 

Improvements

We had a number of misunderstandings as I did not have the rules written down. Sometimes fuzzy rules lead to interesting results, sometimes they frustrate participants.

I would have liked to have spent more time gathering feedback from the participants. Next time I may hold less rounds to give more time for discussions.

Your Turn

You are welcome to try this with your team, I am keen to hear what results you observed…

Not only is it fun, but it is also practical. With one look at our board we can see exactly who is working on what and who they are working with. Each person has one avatar on the board, therefore they can only work on one task at a time. Occasionally someone will start work without updating the board, but this is very seldom.

We went for the classic South Park characters, each team member got to draw themselves, here is the result:

You may have noticed that my character (Daryn) is a bit stressed out. This is a reminder to myself, that as the ScrumMaster I should not get overly concerned about everything. I need to trust in the team and leave them alone to get the job done. I need to remember that a ScrumMaster is a facilitator and not a manager. For me, not acting like a manager is the most difficult part about being a ScrumMaster.