Tutorial – BDD and Dependency Injection in .Net (4)

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());
        }

    }
}

Tutorial – BDD and Dependency Injection in .Net (1)

This tutorial focuses on Behaviour Driven Development, Dependency Injection and application design in general. The primary technologies being used will be SpecFlow and MS Test. While we are targeting the .Net platform the content is applicable to most object oriented languages.

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.