What is BDD (Behaviour Driven Design)?
Posted by Garry Shutler in BDD, BDD from scratch, Unit testing
“What is BDD?” is a question that’s been doing the rounds lately within the altnetgroup and devbookclub. There’s a great deal of mysticism surrounding it as if it were some exclusive members club. I’m going to slay some of the myths and tell you what BDD really is.
Myth 1: BDD requires a framework or tool
You don’t need to use MSpec, RSpec, Cucumber, etc to practice BDD. Sure they can help but they are not a precursor to being a practitioner of BDD. You don’t even have to write your tests within a certain construct such as Given-When-Then.
Myth 2: BDD requires UAT
User Acceptance Testing is a great concept but is one of those practices that only the elite working with an exceptional client get to do in real life. If you have UAT as part of your process, all power to you, but that’s all it is, part of your process. It is not part of BDD. It is merely coincidental that BDD style tests are the best way to express your acceptance tests.
Myth 3: BDD has to be done top-down
It is easier to approach BDD in a top down manner. But much like its easier to put your underwear on first, that doesn’t work for everyone in every situation. Just ask Superman. The proponents of BDD often state things in a radical fashion due to a fear of BDD being thrown in the same pot as TDD. That doesn’t mean that every time they say “you must” they actually mean it.
So what is BDD?
At its core, BDD is TDD done with a specific mindset; testing the intent of the system rather than testing a particular piece of code. The difference is subtle but the effects are large. There’s an entire discipline dedicated to the power of semantics after all.
It is the difference between “when I add a new post to my blog, the new post shows up on my homepage” and “calling the create new post method on the blog controller saves a new post and the new post is passed to the homepage view when the home controller’s index action is called”. Both sentences describe the same code, the BDD style signals the intent and is decoupled from the implementation. The non-BDD style describes what the code is doing almost line for line. The decoupling of the tests from the implementation is where the largest benefit of BDD comes from. Your tests will be less brittle making refactoring easier, perhaps even fun, making your code more malleable.
The myths aren’t completely unfounded, using constructs such as Given-When-Then helps enforce the required mindset. Frameworks such as MSpec, RSpec, Cucumber or even a bespoke one help you write tests within that construct. Working from the top-down helps you work from the behaviour of the user interface down to the behaviour of the data access. UAT helps you drive the behaviour of the system from the requirements of the client.
That’s all these things do though, help you develop in the BDD style. You can still write your code in a non-BDD style using all these frameworks, tools and processes, just as you can develop in the BDD style using none of them.
BDD is a state of mind.
or 
BDD from scratch – Build your own framework (Part 2)
Posted by Garry Shutler in BDD from scratch, Quality, Refactoring, Unit testing
In part one I covered how to organise your tests into the Given-When-Then style through the use of an abstract base class. In this post I’m going to show how you can manage your mocks more efficiently. Though not really a part of BDD I’ve found it very useful in clarifying the behaviour described in my tests as it reduces the amount of noise caused by the definition of variables.
I’m going to walk you through an example test, starting off with what we finished off with in part 1. We are going to be testing this standard ASP.NET MVC controller method:
namespace RobustSoftware.BddFromScratch.WebApplication.Controllers
{
public class BooksController : Controller
{
private readonly IBookService bookService;
private readonly IAuthenticationService authenticationService;
public BooksController(IBookService bookService, IAuthenticationService authenticationService)
{
this.bookService = bookService;
this.authenticationService = authenticationService;
}
public ViewResult YourBooks()
{
var currentUser = authenticationService.CurrentUser();
ViewData.Model = bookService.OwnedBy(currentUser);
return View("YourBooks");
}
}
}
I’m going to be using Moq as my mocking framework for this test; again I’ve applied the same concept to other frameworks such as Rhino Mocks. Here is how our test starts out:
namespace RobustSoftware.BddFromScratch.WebApplication.Test.Controllers.Books
{
public class DisplayingYourBooks : BehaviourTest
{
private MockFactory factory;
private BooksController controller;
private Mock<IBookService> bookService;
private Mock<IAuthenticationService> authenticationService;
private ViewResult result;
private List<Book> yourBooks;
private User currentUser;
protected override void Given()
{
factory = new MockFactory(MockBehavior.Loose);
bookService = factory.Create<IBookService>();
authenticationService = factory.Create<IAuthenticationService>();
yourBooks = new List<Book>();
currentUser = new User();
authenticationService.Setup(x => x.CurrentUser()).Returns(currentUser);
bookService.Setup(x => x.OwnedBy(currentUser)).Returns(yourBooks);
controller = new BooksController(bookService.Object, authenticationService.Object);
}
protected override void When()
{
result = controller.YourBooks();
}
[Then]
public void ShownYourBooksView()
{
Assert.AreEqual("YourBooks", result.ViewName);
}
[Then]
public void PassedListOfYourBooks()
{
Assert.AreSame(yourBooks, result.ViewData.Model);
}
}
}
The obvious step to reduce the amount of test code on display would be to move the setup of the MockFactory up into the base class. We’re going to take it a step further than that though and introduce a mock management class. Here is what it looks like:
namespace RobustSoftware.BddFromScratch.Framework
{
public class MockManager
{
private readonly MockFactory factory;
private readonly IDictionary<Type, object> mockDictionary;
public MockManager()
{
factory = new MockFactory(MockBehavior.Loose);
mockDictionary = new Dictionary<Type, object>();
}
public Mock<T> Mock<T>() where T : class
{
var type = typeof(T);
if (!mockDictionary.ContainsKey(type))
{
mockDictionary.Add(type, factory.Create<T>());
}
return mockDictionary[type] as Mock<T>;
}
}
}
This is a wrapper around a dictionary of mock objects. When we ask for a mock that has not been requested before, one is created. Otherwise, the previously created mock is retrieved from the dictionary and returned. We’ll add the creation of the mock manager to our abstract base class and expose the Mock<T> method for use within our tests:
namespace RobustSoftware.BddFromScratch.Framework
{
[TestFixture]
public abstract class BehaviourTest
{
private MockManager mockManager;
protected Mock<T> Mock<T>() where T : class
{
return mockManager.Mock<T>();
}
[TestFixtureSetUp]
public void Setup()
{
mockManager = new MockManager();
Given();
When();
}
protected abstract void Given();
protected abstract void When();
}
}
Now we can utilise the mock manager within our original test, reducing the lines of code considerably:
namespace RobustSoftware.BddFromScratch.WebApplication.Test.Controllers.Books
{
public class DisplayingYourBooks : BehaviourTest
{
private BooksController controller;
private ViewResult result;
private List<Book> yourBooks;
private User currentUser;
protected override void Given()
{
yourBooks = new List<Book>();
currentUser = new User();
Mock<IAuthenticationService>().Setup(x => x.CurrentUser()).Returns(currentUser);
Mock<IBookService>().Setup(x => x.OwnedBy(currentUser)).Returns(yourBooks);
controller = new BooksController(Mock<IBookService>().Object, Mock<IAuthenticationService>().Object);
}
protected override void When()
{
result = controller.YourBooks();
}
[Then]
public void ShownYourBooksView()
{
Assert.AreEqual("YourBooks", result.ViewName);
}
[Then]
public void PassedListOfYourBooks()
{
Assert.AreSame(yourBooks, result.ViewData.Model);
}
}
}
As we no longer have to worry about variable declaration and assignment for our mocks, we can leave the test code to signal the intent of our test. As there is no real setup for the fields currentUser and yourBooks, I’d be tempted to in-line those variables but this is a matter of personal taste:
namespace RobustSoftware.BddFromScratch.WebApplication.Test.Controllers.Books
{
public class DisplayingYourBooks : BehaviourTest
{
private BooksController controller;
private ViewResult result;
private List<Book> yourBooks = new List<Book>();
private User currentUser = new User();
protected override void Given()
{
Mock<IAuthenticationService>().Setup(x => x.CurrentUser()).Returns(currentUser);
Mock<IBookService>().Setup(x => x.OwnedBy(currentUser)).Returns(yourBooks);
controller = new BooksController(Mock<IBookService>().Object, Mock<IAuthenticationService>().Object);
}
protected override void When()
{
result = controller.YourBooks();
}
[Then]
public void ShownYourBooksView()
{
Assert.AreEqual("YourBooks", result.ViewName);
}
[Then]
public void PassedListOfYourBooks()
{
Assert.AreSame(yourBooks, result.ViewData.Model);
}
}
}
As you can see, this reduces the amount of code required to establish the same context to test a given behaviour. The less lines of code you need to set up a test, the easier it is going to be to understand that test in the future. This, along with the more explanatory naming of your test, makes it much easier to maintain that test in the future.
Next up, I’ll show how we can utilise our MockManager to implement auto mocking. This will reduce the amount of code in our test slightly, but more importantly it makes our test suite less brittle.
Related posts
or
BDD from scratch – Build your own framework (Part 1)
Posted by Garry Shutler in BDD from scratch, Quality, Refactoring, Unit testing
BDD is a higher level of unit testing, it creates better documentation of your system by recording its intent which makes your system easier to learn for new developers and relearn for when you revisit your code further down the line.
I’m going to show you how to build your own BDD testing framework on top of a vanilla unit testing framework. For my example I’m going to use NUnit but I’ve applied the same principles with MbUnit, xUnit and it should work with any other unit testing framework too.
What’s good about doing things this way, as opposed to using a purpose built BDD framework like MSpec, is that it allows your tests to exist and be run side-by-side with traditional unit tests. This can ease the migration to the new style if you’re all moving over to it and it lets you write tests in the BDD style for some parts of the system whilst sticking with the traditional unit style for other parts. Though I’ll be amazed if you don’t end up writing all your tests in the BDD style as everyone I’ve shown it too loves it.
I’ll show you how to create the basis for your own BDD framework and I’ll give an example of how a BDD style test looks in comparison to a traditional unit test.
What is BDD all about?
The core concept of BDD is Given-When-Then (often referred to as Arrange-Act-Assert):
- Given the system is in a certain state (the context of the test)
- When an action is performed on the system (normally calling a single method)
- Then a list of assertions should be satisfied
Herein lies another fundamental difference with BDD, you will create a test fixture per scenario rather than a fixture per class as it common with traditional unit testing.
The basis of our framework
The way to transform your standard unit testing framework to a BDD one is to use an abstract base class. This will modify how your tests are run, giving you the ability to specify your Given, When and corresponding Thens separately from one another:
using NUnit.Framework;
namespace RobustSoftware.BddFromScratch.Framework
{
[TestFixture]
public abstract class BehaviourTest
{
[TestFixtureSetUp]
public void Setup()
{
Given();
When();
}
protected abstract void Given();
protected abstract void When();
}
}
This means that the contents of your Given and When methods will be run once before each of your methods decorated with the Test attribute are run. This is important as it means that all your assertions should not have side effects (this should be the case already). You will use it in a test class by doing something like this:
using System;
using NUnit.Framework;
namespace RobustSoftware.BddFromScratch.Framework
{
public class ExampleBehaviour : BehaviourTest
{
protected override void Given()
{
// the system is setup in a certain state
}
protected override void When()
{
// a defined action is performed on the system
}
[Test]
public void ThisAssertionShouldBeSatisfied()
{
Assert.IsTrue(true);
}
[Test]
public void AnotherAssertionShouldBeSatisfied()
{
Assert.IsTrue(true);
}
}
}
Notice that the intent verified by each assertion is documented in the name of the test method. This means that when you run your tests, the name of the tests themselves show you when was meant to happen rather than the error messages that most people forget to add to their assertions.
Another thing that I like to do but is entirely optional is alias the Test attribute to be able to use a Then attribute with the same behaviour:
using NUnit.Framework;
namespace RobustSoftware.BddFromScratch.Framework
{
public class ThenAttribute : TestAttribute
{
}
}
This just changes the original example test slightly so it’s more obvious how the Given-When-Then style is being applied:
using System;
using NUnit.Framework;
namespace RobustSoftware.BddFromScratch.Framework
{
public class ExampleBehaviour : BehaviourTest
{
protected override void Given()
{
// the system is setup in a certain state
}
protected override void When()
{
// a defined action is performed on the system
}
[Then]
public void ThisAssertionShouldBeSatisfied()
{
Assert.IsTrue(true);
}
[Then]
public void AnotherAssertionShouldBeSatisfied()
{
Assert.IsTrue(true);
}
}
}
Converting a traditional test
I’ll start of with what I think to be a pretty standard unit test that I found in the source of OpenRasta:
[Test]
public void a_change_after_a_creation_results_in_a_new_oject_with_the_same_properties()
{
var binder = new KeyedValuesBinder("customer", typeof(Customer));
binder.SetProperty("username", new[] { "johndoe" }, (str, type) => BindingResult.Success(str));
binder.BuildObject();
binder.SetProperty("firstname", new[] {"john"}, (str, type) => BindingResult.Success(str));
var customer = (Customer)binder.BuildObject().Instance;
customer.Username.ShouldBe("johndoe");
customer.FirstName.ShouldBe("john");
}
As I see it this, like many other traditional unit tests, is already split into the Given-When-Then style logically:
[Test]
public void a_change_after_a_creation_results_in_a_new_oject_with_the_same_properties()
{
// Given - the context we are establishing in the system
var binder = new KeyedValuesBinder("customer", typeof(Customer));
binder.SetProperty("username", new[] { "johndoe" }, (str, type) => BindingResult.Success(str));
binder.BuildObject();
binder.SetProperty("firstname", new[] {"john"}, (str, type) => BindingResult.Success(str));
// When - the action we are performing on the system
var customer = (Customer)binder.BuildObject().Instance;
// Then - checking the system ends up in the desired state
customer.Username.ShouldBe("johndoe");
customer.FirstName.ShouldBe("john");
}
So splitting it physically into the separate sections is not much of a leap:
public class ChangingAnObjectAfterACreation : BehaviourTest
{
private KeyedValuesBinder binder;
private Customer customer;
protected override void Given()
{
binder = new KeyedValuesBinder("customer", typeof(Customer));
binder.SetProperty("username", new[] { "johndoe" }, (str, type) => BindingResult.Success(str));
binder.BuildObject();
binder.SetProperty("firstname", new[] { "john" }, (str, type) => BindingResult.Success(str));
}
protected override void When()
{
customer = (Customer) binder.BuildObject().Instance;
}
[Then]
public void UsernameShouldBeJohnDoe()
{
Assert.AreEqual("johndoe", customer.Username);
}
[Then]
public void FirstNameShouldBeJohn()
{
Assert.AreEqual("john", customer.FirstName);
}
}
I've dropped the use of the assertion extension methods that Sebastien Lambla was using (I’ll cover how to write those later in the series), but otherwise the actual test code has remained the same.
The physical separation of the logical parts of the test makes the test easier to follow and the assertions at least as explicit even without the extension methods being used.
The fact that BDD makes the separation many people already make when writing traditional unit tests more explicit is why I and other people like it. It makes your tests more readable as you can often skim the Given section as that should be conveyed by the name of the entire fixture. That leaves you to see what method is being called and the assertions being made. These are often now more descriptive as they are given a method name.
If you’ve got any questions, leave a comment and I’ll reply as soon as I can. Do the same if you’ve any related topics you’d like to see covered. I’m planning on covering, mock management, auto-mocking, fluent test extensions and shared contexts.
Related posts
or
If your code isn't tested, it doesn't work
Posted by Garry Shutler in Quality, Unit testing
I test-drive my code. That means, by definition, that each line is covered by at least one test. I know my code works today and tests ensure it still works tomorrow, next week and next year.
If your code isn't tested you may know it works today, after drawn-out manual testing through each scenario. But what about tomorrow? Are you going to do the manual tests for today's work? Come next week are you going to be performing manual tests for this week's work? Of course you're not, you'd never get anything done.
By testing your code you are eliminating the majority of emergent bugs as soon as they happen (you are doing continuous integration aren't you?). This means you produce features faster in the medium to long term as you minimise the number of bugs that arise. A win for business as costs are reduced as well as lead time. I don't know about you but I prefer adding features to chasing bugs too.
If you're not testing, you must enjoy debugging.
or
A better domain event raiser
Posted by Garry Shutler in Refactoring, Unit testing
There was a lot of discussion about domain events at AltNetUK around Udi Dahan's recent article. Please read that first so that you’ll know the context of what I’m about to say, I’ll still be here. Might be useful to have them side-by-side.
I couldn’t help when reading it that the code around event dispatching was quite a mess, with code added in for multiple, distinct scenarios (live and test). This may just have been to help with the formatting of the article, but it leaves a lot to be desired.
What I’m going to do here is show my refactored version of the code and explain why I think it is better. What I’m going to be doing is utilising the strategy pattern to separate the logic of dispatching events from the action of requesting an event to be dispatched.
In figure 1 of the testability section Udi shows how the DomainEvents class ends up. Here is how mine looks after the refactoring:
public static class DomainEvent
{
public static IEventDispatcher Dispatcher { get; set; }
public static void Raise<TEvent>(TEvent eventToRaise) where TEvent : IEvent
{
Dispatcher.Dispatch(eventToRaise);
}
}
This is made possible because I’ve abstracted the dispatching of the event into a separate class implementing the IEventDispatcher interface:
public interface IEventDispatcher
{
void Dispatch<TEvent>(TEvent eventToDispatch) where TEvent : IEvent;
}
There would be two implementations of IEventDispatcher in normal projects. One to be used at runtime such as this one utilising StructureMap:
public class StructureMapEventDispatcher : IEventDispatcher
{
public void Dispatch<TEvent>(TEvent eventToDispatch) where TEvent : IEvent
{
foreach (var handler in ObjectFactory.GetAllInstances<IEventHandler<TEvent>>())
{
handler.Handle(eventToDispatch);
}
}
}
And one to be used during unit tests such as this one:
public class ActionEventDispatcher : IEventDispatcher
{
private readonly IDictionary<Type, Delegate> handlers;
public ActionEventDispatcher()
{
handlers = new Dictionary<Type, Delegate>();
}
public void Register<TEvent>(Action<TEvent> eventAction) where TEvent : IEvent
{
// assuming you'll only register once per test
handlers.Add(typeof(TEvent), eventAction);
}
public void Dispatch<TEvent>(TEvent eventToDispatch) where TEvent : IEvent
{
if (!handlers.ContainsKey(typeof (TEvent))) return;
var handler = (Action<TEvent>) handlers[typeof (TEvent)];
handler.Invoke(eventToDispatch);
}
}
You’ll notice that the two event dispatchers are the two sides that can be executed in Udi’s implementation. That is the essence of the strategy pattern.
This does modify the test slightly so that you now have to do this:
[Test]
public void DoSomethingShouldMakeCustomerPreferred()
{
var c = new Customer();
Customer preferred = null;
var eventDispatcher = new ActionEventDispatcher();
DomainEvent.Dispatcher = eventDispatcher;
eventDispatcher.Register<CustomerBecamePreferred>
(p => preferred = p.Customer);
c.DoSomething();
Assert(preferred == c && c.IsPreferred);
}
I would put the attachment of the ActionEventDispatcher into a test base class so that you didn’t have to set it up for every test, reducing the noise added.
You would also have to add a small bit of code to hook up your real event dispatcher when your application started:
public void SetEventDispatcher()
{
DomainEvent.Dispatcher = new StructureMapEventDispatcher();
}
Still not sure whether I like the use of domain events or not. However, I did notice this potential refactoring whilst reading the article and thought it was interesting enough to blog about. I think it has left the code in a much better state and I think it also addresses some of the concerns that were raised about the static class at AltNetUK.
or
POST overload – implementation considerations
Posted by Garry Shutler in ASP.NET MVC, REST
As I have been blogging about, I’ve been fighting with myself over the best way to implement POST overloading in RESTful ASP.NET MVC. I’m still not happy that I have chosen the best implementation in using the URL to indicate the overload but I’m done with thinking about it for now. I’m going to record my and others thoughts about the pros and cons of each approach and move on to other functionality.
The two main points around which the discussion revolves are transparency and adherence to the spirit of HTTP. A compromise has to be made on one of them, which you choose to compromise, I feel, is a personal decision.
Using a hidden form value for overloading is transparent to the user, the URL the POST is made to does not change. My previous argument for needing to implement overloading for different content types is nonsense as you would never need to use POST overloading apart from when POSTing a form from a browser. All other calls will be able to use the correct HTTP verb directly.
The URL overloading method, for me, remains closer to the spirit of HTTP. If the URL contains the overload you know how to handle the request purely from the head of the HTTP request. Using the form value method you need to check the body of the HTTP request to know what to do.
Neither method is ideal, they both have their compromises and I can’t honestly say whether one is better than the other at the moment. Perhaps I’ll obtain some insight later that makes one clearly better than the other. However, I do know that at the moment I’m risking the wrath of Scott Bellware:
@gshutler ultimately, i'm gonna come gunning for you if this hack-in-the-uri becomes convention in the late-to-the-game .net rest users :) Sat 25 Jul 01:20
If you find me in a ditch because everyone starts using the URL overload method, you have a prime suspect.
I’d like to thank Scott Bellware and Sebastien Lambla for taking the time to talk to me about this subject over the past couple of weeks on twitter, it’s greatly appreciated.
or
Overloading POST – a change of mind
Posted by Garry Shutler in ASP.NET MVC, REST
Today I made a fairly fundamental change in design of RESTful ASP.NET MVC revolving around how I will be overloading post for HTML forms.
Previously I was adding a hidden field to the form, which is how it is done by Rails:
<form method="POST" action="/Users/2">
<input value="DELETE" type="hidden" name="_method" />
<input value="Delete" type="submit" />
</form>
I was aware of OpenRasta's method of overloading post which is to append the overload to the URI:
<form method="POST" action="/Users/2!DELETE">
<input value="Delete" type="submit" />
</form>
However, I didn’t like the way the overload was opaque to the user and thinking that the Rails guys must have thought about it a fair bit I initially went with the former method.
I ended up having a discussion with Sebastien Lambla, the developer of OpenRasta, about the two options and why he had chosen the second method over the first (I love twitter for this). To be honest, I came away from the discussion thinking there wasn’t much to chose between the two, it just being down to a matter of preference. However, I kept thinking about it, questioning my decision and whether it my choice really was better than the other option.
I had a moment of clarity whilst playing golf. I realised that, potentially, I might have to write post overload mechanisms for multiple formats as clients could submit requests in a variety of formats (XML, JSON, form, etc). If the overload is contained within the URL then the overload is independent of the body’s content type, simplifying things considerably.
Now I had a reason to change, I did so, changing RESTful ASP.NET MVC’s method of overloading post to the URI mechanism. As it happens this tidied up the code a little as I no longer had to pass around the form collection, I could work purely off the routing values.
Related posts:
You should subscribe to my feed to keep up with development of RESTful ASP.NET MVC.
UPDATE
I have written a follow-up post about the implementation considerations for POST overload that I recommend reading as well.
or
