Everything pulls from the defined scenarios

The main thing I like about the BDD workflow is that it gives you great structure around how to approach a project. Often when you first start something new it can be a little daunting to know where to begin – whether you start designing a schema, writing some unit tests (which tests, where do you start…), if you begin by writing up some user stories and apply an agile structure around it etc.

The great thing with BDD is that you are either writing some new features or scenarios using a plain English language, or you are implementing tests to deliver those scenarios. Every piece of code that you write and every test should be directly ‘pulling’ from the defined scenarios. As soon as you have finished implementing tests to prove a given scenario, you move on to the next. If you run out of scenarios, you either write some more scenarios for the current feature, or you begin defining a new feature. At any point in time, you pretty much know exactly what to do next.

How does BDD affect unit tests?

A big area of confusion that I initially had was how BDD affects unit testing – whether unit tests are effectively replaced by the natural language scenarios, and if you are testing more granular technical detail if you are meant to try to express this from an end user point of view with the scenarios etc.

A user’s experience with software is entirely based on the interactions they have with the user interface. Therefore it makes sense to define the expected behaviours from a user’s point of view, in terms of what the current situation is (Given), what action they take (When) and what the expected result is (Then).

It works quite well to have executable tests for these scenarios to test the user interface, and mock the dependencies. In my project this means testing the MVC controllers and action methods, but mocking the application services. Using a mocking framework you set up the expected behaviour from the dependencies in the ‘Given’ steps, the ‘When’ steps execute the action method on the controller, and the ‘Then’ steps verify things like the ActionResult and the ViewData.

You absolutely need unit tests to verify the behaviour of the lower level components, but the point is that the test scenarios that you write and the expected behaviours are all ‘pulling’ from the requirements in the defined BDD scenarios. If at any point you’re unsure of whether you have the correct set of test cases, you should refer back to the plain English scenarios, read through the expected behaviours, then ensure that your unit tests are set up to verify the correct thing.

This really means that the BDD automated acceptance tests and unit tests do both sit well together. The difference is that the BDD tests give the overall context that you’re working to, and provide a focal point about what you should be testing and why.

Language used in unit tests

BDD talks quite a lot about the importance of language used, and how the word ‘test’ implies checking something after the event. Unit tests are all about defining expected behaviours, so the word ‘should’ is much more appropriate. I have to admit, initially I quite seemed like a pretty unimportant distinction to me, and I didn’t quite get it. However I’m now totally convinced.

Previously I would have pretty much created a test fixture per class, and the unit tests names would have probably ended up being oriented around the technical implementation. For example, testing an application service might result in a test fixture called SecurityServiceTestFixture.

I’ve taken to creating a test fixture for each action or process, then starting each unit test method with ‘Should’ to express a particular facet of the expected behaviour. Using the same example, I might create a fixture called RegisteringANewUser and the unit test would be called something like ShouldSendAnEmailToVerifyTheUserEmailAddress.

Although this is quite a subtle distinction it makes it much easier to work out what test cases there should be, and to read back through and understand exactly which behaviours are being tested. It’s also easier to read the original scenario definition, read through your unit tests and get a sense of whether everything is covered.

Composition of a unit test

The actual way that a unit test is put together is pretty much unaffected – you’ll generally go with the same arrange, act assert pattern. The only change that I’ve really had to make is organising the test fixtures, and the language that I use for the test methods.

BDD Workflow

Putting all of this together gives you the following kind of workflow…

• You start with the Gherkin based scenarios defined in plain English
• You bind each scenario step to an executable method, and test your user interface
• During this process you use interfaces for any dependencies, and mock these to verify the UI behaviour
• Once the UI tests are passing, you look at each dependency and write lower level unit tests to cover the expected behaviours
• For each dependency, you look at any further dependencies and write unit tests to cover these additional components
• Work to get each unit test passing
• If at any point you get confused about which unit test cases to write, refer back to the scenario definitions to have a clear set of requirements about the expected behaviours
• Either move on to the next scenario, or define some more scenarios

Obviously there are solutions to this problem, the foremost being to set up a project wiki. However I’m quite fussy about design and interaction, and the way that software feels when you use it, and I’ve yet to find a wiki product that makes me feel good. I want something that is addictive and satisfying to use, that engages you and makes you want to work with it. The idea being to build a multi-tenant application that can host project knowledge for teams.

Based on this I’ve started work on TeamBrain, hosted on Codeplex. Feel free to grab a copy of the source and talk to me as it develops. I have some time off work so will be trying to flesh it out over the next few weeks.

I’m also taking the opportunity to try out a few new technologies and things I’ve wanted to take a look at for a while. The one I’m most excited about is BDD (Behaviour Driven Design). I’ll be running the project by defining features and scenarios in SpecFlow, and having all of the unit tests and behaviour pulling from the defined scenarios. If you want to learn more, I suggest starting with this screencast which gives a really great introduction. I’ll post some examples and hints as I learn along the way.

However in this instance I’m working with a large legacy codebase. Even with the best intentions people won’t stick to a convention unless it gets enforced, and based on the amount of code that doesn’t comply it isn’t very simple to start enforcing the standard.

The only solution I could really see was to swallow the pain and go and reformat all of the existing code, then start enforcing analysis on the projects that have been updated.

I don’t think this would have even been possible if it hadn’t been for Resharper 5 and the StyleCop for Resharper plugin. I’ve become massively more productive since using Resharper a few weeks back and in this instance it’s been simply awesome.

Code Cleanup

Once Resharper has been configured with the StyleCop plugin so all coding style conventions are set up, you can run the code cleanup feature against a file or folder (Ctrl-Shift-Alt-F) which will reformat all existing code based on the configured rules. In my case this will typically reduce a file from around 300 violations to about 8. You can set up a profile to control exactly what does or does not get changed as part of this process.

Cycle through code issues (F12)

The next most useful feature is that StyleCop violations are treated as code issues by ReSharper. Hitting F12 repeatedly within a code file will jump to the next issue making it very simple to navigate around all violations and clean them up.

Violation highlighting within editor

The plugin will also highlight any style violation as you code, and provide tooltips and messages in the status bar to indicate what the violation was.

It will still take a while to finish updating the existing codebase, but I’m not even sure it would be feasible to attempt this without these tools.

This fits in very nicely with some of the ideas in Behaviour Driven Design, which is like the next iteration of thinking around TDD. The idea is to express acceptance tests using a simple DSL vocabulary working in plain English, then hook up each acceptance test scenario to some automated tests which prove the scenario works as expected.

A simple example would be…

+Title: Customer withdraws cash+
As a customer,
I want to withdraw cash from an ATM,
so that I don’t have to wait in line at the bank.

In BDD, an acceptance test would be along the lines of…

+Scenario 1: Account is in credit+
Given the account is in credit
And the card is valid
And the dispenser contains cash
When the customer requests cash
Then ensure the account is debited
And ensure cash is dispensed
And ensure the card is returned

I’ve lifted the example here from the key article published on BDD from Dan North – if you’re interested so far then you should stop reading now and go and check out the article.

BDD frameworks will then map each step expressed in the text above through to a method in a test class, so you have a great balance between expressing the acceptance tests in simple language, but having the ability to execute the tests.

I found the best way to learn about this so far was a TekPub video – you’ll need a subscription, but the video is under the ‘Concepts’ section > Concepts:5 Behaviour-driven Design with Specflow.

Overall it seems like a more natural way to approach proving the application behaviour, and makes it much easier for testers and analysts to work alongside you in defining acceptance tests. I’m quite keen to roll this into our day-to-day process.