Next week I’ll be presenting at the PrairieDevCon in Regina and one of my presentations is about Behavior Driven Development, how to apply it using .NET tools like SpecFlow, Nunit, Watin, Cassini, MbUnit, etc.

Because is a Dojo/Code with me presentation I’m planning to do a BDD exercise with all the attendees to show them how to describe a new feature using BDD and implement it together.

We will start with a project that has one feature implemented, and will code together the second feature using full BDD and TDD.

So, what should I use to illustrate BDD? No other than my old friend the MediaLibrary example that I used quite a few times, but now including a full BDD implementation.

MediaLibrary

The MediaLibrary project is a web application that  allows the user to register and catalog his collection of movies, books, games, etc.

I’m using GitHub to publish the code we are going to use in the Dojo. Right now the latest version represents the code that I’m going to start with.

If you would like to check out the code I’m going to use please go to the PrairieDevCon page on my blog and get the code from GitHub, read the README file to verify you have the requirements installed and the application is working.

Do you have everything installed? Did you read the README file? Cool, open the solution and let’s move on!

Using BDD

Behavior Driven Development is a term used to describe (in our case) development that starts by writing the feature (or user story) that we want to implement. Once we have the feature, we will use a “story runner” that will run the feature we just wrote and show if the story is actually implemented as we wanted or not yet. If it is, good, everything should be “green”. If not, we get a “red”, and we have to add code and implement more functionality to make it pass.

To write the user story we are going to use a particular syntax from the Gherkin language. The Gherkin language has very few rules, please read the introduction for Cucumber from Aslak Hellesoy.

Let’s see the feature that it’s implemented in the code, Browse Movies:

Feature: Browse Movies
    As a User
    I want to Browse Movies
    So I can see the contents of the library

    Scenario: Browse available movies
        Given I have the following movies:
          | title           |
          | Blazing Saddles |
          | Space Balls     |
        When I go to Movies
        Then I should see in the listing:
          | title             |
          | Blazing Saddles   |
          | Space Balls       |

What is most important here is to look at the scenario. The scenario is describing that if you have movies A, B and C in the library, when you browse you should see the same movies on the Movies page.

Now if we want to check the feature manually, what would we do? Something like this:

1. Add the movies to the storage
2. Start the web application
3. Launch the browser
4. Go to the movies page
5. Check that all the movies in the storage are listed in the browser

The thing is that I don’t want to validate each feature (with many scenarios) manually, I’d like the scenario/feature runner to do that for me, add the movies, launch the browser and check, everything automated following the steps I wrote in my scenario.

Probable we could manage to write code that will do that for us, now, the question is how the scenario runner translates this feature into actual code? If we were using rails we could use Cucumber, but luckily for the .NET world we can use SpecFlow (IronRuby too, but that’s another post).

Given That I have the following movies

Specflow is a tool that understands Gherkin and generates an NUnit test for every feature that we use. Being an NUnit test, simplifies how we going to run the specification. Just run the NUnit test with your favorite test runner: ReSharper, NUnit (console or GUI), MbUnit, etc.

Each scenario is composed by a series of steps, each step is identified by a Gherkin keyword, in our feature we found Given, When and Then.

The NUnit test has code for each scenario and will invoke the steps indicated in the scenario.

In order to do so, Specflow uses the text that we write in the step, to match the code.

Let’s look at our first step “Given I have the following movies:”. In order to implement the step, in the code, you will find a method that looks like:

[Given(@"I have the following movies:")]
public void AddMovies(Table movies)
{
    movies.Rows.ForEach(row => AddMovieToStorage(row["title"]));
}

The Given attribute is used to match the text we wrote in the scenario, to indicate the the method AddMovies should be called when the step is invoked.

The step in the scenario indicates that the method receives a series of rows should be passed as parameter (first row is the title, every column separated by “|”), that is why it receives a Table.

In the implementation for each movie in the table, the title will be added to the storage. Check the method AddMoviesToStorage for more details.

Now that we setup our storage we are ready to move on and launch the browser.

When I go to Movies

The next step to implement implies opening the browser and going to the Movies page to see the listing.

Now, to do so we need two things, first the web application running and then to launch a browser to go the actual page.

To run the application I’m going to use Cassini web server. The setup of the features will start the web server and stop it when it’s not needed any more. We can see the implementation in the Browser class under Utililty.

static Browser()
{
    WebServer = new Server(Port, "/", GetPhysicalPath());
}

With the server running, we now need to launch the browser and automate the checking for all the movies.

For that we are going to use Watin. Watin (Web automation test in .NET) is a library that helps us to manipulate the browser (based on Watir) and also give us all the HTML for the page we are visiting.

We can see the use of the IE instance in the Browser class:

public static void InitializeBrowser()
{
    WebServer.Start();

    Instance = new IE(ApplicationURL);
}

public static void ShutdownBrowser()
{
    Instance.Close();

    WebServer.Stop();
}

Now that we have our server running, and our IE instance, we only need to go to the right path. In this case we want to go to “/Movies”. For that let’s look at the NavigationSteps class:

[When(@"I go to (.*)")]
public void WhenIGoToPage(string pageName)
{
    Browser.GoTo(PathFor(pageName));
}

The step uses the browser to navigate to the right page. The page is passed as a parameter that we can see in the attribute as a regular expression.

So far, so good. Now, our last step is to check for the movies in the page to make sure that all of them are in the list.

Then I should see in the listing

To implement the last step in our scenario we are going to use the following implementation:

[Then(@"I should see in the listing:")]
public void AssertListingContains(Table movies)
{
    var expected = movies.Rows.Select(row => row["title"]);

    var listing = this.Page.Listing;

    listing.Should().Have.SameSequenceAs(expected);
}

Again we are using a step that takes a table as parameter, so we iterate thru the table and get the titles of all the movies that should be in the page.

The code has no mysteries except the Page property.

public ListingSteps()
{
    this.Page = new BrowseMoviesPage();
}

The Page property is initialized in the constructor and the goal of the BrowseMoviesPage is to abstract the internals of how the movies are listed in the page. For example, right now the view that implements the listing of movies uses a table for each movie, however it could use a DIV or some other tag. Here is the implementation:

public IEnumerable<string> Listing
{
    get
    {
        var elements = Browser.Instance.TableCells.Where(cell => cell.ClassName == "title");

        return elements.Select(e => e.InnerHtml.Trim());
    }
}

As we can see, the code is getting all the table cells where the CSS class is title and then getting the inner html and trimming it.

If we would have to use this code every time we want to check the listing we would have code duplication, plus if the implementation of the view changes, we would have to modify each piece of code that refers to this page. Using the PageObject pattern we avoid code duplication and it’s easy to change the implementation.

And voila! We got all our steps implemented.

What’s next?

If you join me next week on the Prairie Dev Con, we will implement the next feature together “Add Movies”.

What’s so cool about BDD? Please go ahead and run “rake test:features” on the command line, and you’ll see that the steps for the second feature are still pending, that means that they are not implemented yet.

Writing the feature first we manage to describe what we want, and implementing step by step we make sure that we are working towards make the feature pass. BDD on the outside and TDD on the inside.

Hope to see you all next week in the conference!

If you are wondering why you should test your code or why using Test Driven Development is a great advantage then please check Wikipedia, AgileData and Kent Beck’s book. If you are convinced so far, please read on.

Testing Automation

Writing tests allow us to prove that our code work as expected. Having tests written also allow us to run all our tests every time new code is added to make sure that nothing broke so far.

Continuous Integration is a common practice used to build, test and deploy every time the code changes in the repository. Because the build script is run from our CI server,  our tests should be designed and written to run without external dependencies or with few as possible. If you want to read more about continuous integration you can read Martin Fowler’s article about it.

I have a DB, where should I start?

First of all we need to model our Data Access Layer (DAL for short) to provide access to the storage.

The DAL provides the interfaces and classes that will abstract our application from our target storage. Thus if we decide to use LINQ to SQL or ADO Entity Framework or Castle ActiveRecord as implementation the DAL does not change and does not impact the rest of our application. Different needs may require different DAL implementations, we can even use REST services to access our storage with the same DAL.

As an example to illustrate the testing let’s imagine we have a DAL to represent a media library. A media library is a library that stores DVDs, games, music for a user. Here is a small diagram to describe the structure I’m planning to use:

DAL, SHMAL, what about testing?

So far, so good. We have our DAL and before writing our first class, let’s think about what we need to write the test.

The test should check that our concrete DAL implementation is querying/modifying the database in the expected way. In order to do that, I can think of the following requirements:

• Try to minimize dependencies (if possible) with the database in order to run the test stand alone.
• Each test should start from a valid clean database (need a way of create/drop the schema).
• The database should be deleted after the tests are done.

Because we have the same requirements for all our tests I think a base class would suit our needs and provide common functionality. Let’s call it BaseDbTest.

To fulfill our requirements I’m going to take advantage of MbUnit initialization and clean up events:

• FixtureSetUp: Runs before all the tests in the class are run.
• SetUp: Runs before each test is run.
• TearDown: Runs after each test is run.
• FixtureTearDown: Runs after all the test in the class are run.

So, how to use these events for our goal? Let’s see:

• FixtureSetUp: Create the database and initialize framework.
• SetUp: Create the schema and populate the database.
• TearDown: Drop the schema.
• FixtureTearDown: Drop database.

And here is the code for the test:

        ///
        /// Creates the schema for an empty database
        ///
        [SetUp]
        public void BeforeEachTest()
        {
            CreateSchema();
        }

        ///
        /// Drops the schema to clean the database
        ///
        [TearDown]
        public void AfterEachTest()
        {
            DropSchema();
        }

        ///
        /// Creates a temporary database using a temporary file name and
        /// initializes the entities using the connection string to that database
        ///
        [FixtureSetUp]
        public void BeforeAllTheTests()
        {
            CreateDatabase();
            InitializeFramework();
        }

        ///
        /// Clears up the resources and deletes the database file used
        ///
        [FixtureTearDown]
        public void AfterAllTheTests()
        {
            DeleteDatabase();
        }

That’s a good start. Now we have to think about which database we are going to use for the testing.

Because we would like to minimize the dependencies with any database in order to run the tests in any environment I’m going to use a SQL CE database. SQL CE uses a file as storage and we can generate the file when we need it and then delete it.

So here is the implementation to create and delete the database using SQL CE:

        ///

        /// Creates the database file using a temporary file name
        /// 

        private void CreateDatabase()
        {
            this.DatabaseFileName = Path.GetTempFileName();

            DeleteDatabase();

            var engine = new SqlCeEngine(this.ConnectionString);

            engine.CreateDatabase();
        }

        ///

        /// Deletes the database file
        /// 

        private void DeleteDatabase()
        {
            File.Delete(this.DatabaseFileName);
        }

        ///

        /// Filename to use for the database
        /// 

        protected string DatabaseFileName { get; set; }

Now, we need to create/drop the schema and initialize the framework. To do that we need to chose which framework we are going to use, in this case I’m using Castle ActiveRecord to do it:

        ///

        /// Creates the schema to run the tests
        /// 

        virtual protected void CreateSchema()
        {
            // log the creation script
            // ActiveRecordStarter.GenerateCreationScripts( "c:\\temp\\create.sql");

            ActiveRecordStarter.CreateSchema();
        }

        ///

        /// Connection string to use
        /// 

        protected string ConnectionString
        {
            get
            {
                return String.Format( "Data Source={0};", this.DatabaseFileName);
            }
        }

        ///

        /// Creates the properties and initializes the framework using ActiveRecordStarter
        /// 

        private void InitializeFramework()
        {
            var properties = new Dictionary<String, String>
                                 {
                                     //{"hibernate.show_sql", "true"},
                                     {"hibernate.connection.driver_class", "NHibernate.Driver.SqlServerCeDriver"},
                                     {"hibernate.dialect", "NHibernate.Dialect.MsSqlCeDialect"},
                                     {"hibernate.connection.provider", "NHibernate.Connection.DriverConnectionProvider"},
                                     {"hibernate.connection.connection_string", this.ConnectionString}
                                 };

            var source = new InPlaceConfigurationSource();

            source.Add( typeof(ActiveRecordBase), properties);

            ActiveRecordStarter.ResetInitializationFlag();

            ActiveRecordStarter.Initialize( typeof( MediaElement ).Assembly, source );
        }

        ///

        /// Drops the schema after running the tests
        /// 

        virtual protected void DropSchema()
        {
            ActiveRecordStarter.DropSchema();
        }

Voilá, that’s it. Castle ActiveRecord provides a very convenient way of creating and dropping the schema using the ActiveRecordStarter class. Be mindful that the InitializeFramework runs once before per test class, thus we need to reset the initialization to avoid error messages using ActiveRecordStarter.ResetInitializationFlag().

Last but not least, our first test

To test our implementation let’s start with IMediaLibrary implementation to check that the following cases are true:

• When calling Contents all the media in the database is returned.
• When calling Users all the users in the database are returned.
• When adding media to the library the media is stored

Without further ado:

        ///

        /// Tests that all the users in the database are returned
        /// 

        [Test]
        public void WhenAskingForTheUsersAllTheUsersShouldBeReturned()
        {
            var expected = factory.LotsOf<IUser>();

            var actual = this.mediaLib.Users;

            Assert.IsNotNull( actual, "The users should not be null" );

            var eSorted = expected.OrderBy(e => ((User)e).Id);
            var aSorted = expected.OrderBy(a => ((User)a).Id);

            Assert.Over.Pairs(aSorted, eSorted, Assert.AreEqual);
        }

        ///

        /// Tests that all the media in the database is returned
        /// 

        [Test]
        public void WhenAskingForTheMediaAllTheContentsShouldBeReturned()
        {
            var expected = factory.LotsOf<IMediaElement>();

            var actual = this.mediaLib.Contents;

            Assert.IsNotNull(actual, "The users should not be null");

            var eSorted = expected.OrderBy(e => ((MediaElement)e).Id);
            var aSorted = expected.OrderBy(a => ((MediaElement)a).Id);

            Assert.Over.Pairs( aSorted, eSorted, Assert.AreEqual );
        }

        ///

        /// Tests that when adding new media the collection grows
        /// 

        [Test]
        public void WhenAddingNewMediaTheCollectionShouldHaveOneMore()
        {
            var oldContents = this.mediaLib.Contents;

            var oldCount = oldContents.Count();

            var user = factory.OneUser();

            var added = this.mediaLib.AddMedia<IMovieElement>( "Test", user );

            var actualContents = this.mediaLib.Contents;

            Assert.IsNotNull( added );
            Assert.AreEqual( oldCount + 1 , actualContents.Count(), "The count should be increased by one");
            Assert.AreEqual( added, actualContents.Last() );
        }

To generate another test we just need to write a new class and inherit from BaseDbTest.

To download the full example please click here DbTest source code.

Enjoy.