I've seen BDD in action (in this case using SpecFlow and Selenium in a .NET environment) for a small test project. I was very impressed - mainly due to the fact that the language used to specify the acceptance tests meant they engaged with the product owner much more easily.

I'm now keen to bring this into my current organisation. However I'm asked 'who else uses this?' and 'show me some case-studies'.

Unfortunately I cannot find any 'big names' (or even 'small names' for that matter!) of companies who are actively using BDD.

I have two questions really:

  • Is BDD adopted by companies out there? Who are they?
  • How can BDD be implemented in an agile .NET environment and are there any significant drawbacks to doing it?

2 Answers 2


I've used BDD extensively at many big clients, and seen it used in even more. If your organisation is hesitant about adopting the automation side, you can still focus on having the conversations between testers, developers and business people - this has really helped in a number of places.

At one .NET client we started automating Fitnesse.NET backed by FitSharp, but moved away from it when we realised that everyone who was interested in reading the automated scenarios was technical enough to read code. We were using WPF, so I wrote an automation tool to help us, and mirrored some of the things we were doing in a toy application. You can see the scenarios I wrote here. The way in which I've done this is really similar to what we were doing on the client site. I've also heard good things about SpecFlow, so either way forward should work.

As well as catching the occasional bug, talking through the scenarios really helped us understand what it was we were trying to achieve before we started coding, and we found many edge-cases as a result of the discussions. Every single project I've seen take up BDD has found benefit in it, with the one exception of a project which was only started because the sponsor wanted to use up his budget so he could be sure of getting it again the next year (the transparency around business value in BDD really annoys people who are gaming the system with things like this).

I have also put together a page on BDD which could help anyone who's new to it.

Lastly, you might want to check out Dan North's talk on selling BDD to the business.

  • Many thanks for your input Liz. I've already checked out your blog :-) - a great source. Where are you based? I'm down in Brighton UK. We've decided to use BDD in a pilot project using SpecFlow (and Selenium) - should be interesting. I'll keep you posted. Nov 17, 2011 at 11:51
  • Hi Nick, I'm in Belgium at the moment and will be back in London in December. If you find yourself up our way, come to XtC (Extreme Tuesday Club) - love to chat. Thanks for the kind feedback :)
    – Lunivore
    Nov 18, 2011 at 10:25

No, most companies aren't adopting BDD. Here's why:

  • In theory, BDD has some merit.
  • In practice, especially with a web application, BDD can require more effort than it's worth.

In my experience:

  • Creating BDD grammars is, at best, cumbersome.
  • Mocking HttpContext makes BDD more trouble than it's worth.

I'll allow that a screencast like this one, could make someone excited about BDD.
Unfortunately, the vast majority of real applications are never this straightforward.
Technical debt, often accumulated during schedule crunches, clutter most applications to a point where they aren't amendable to BDD.

  • 1
    BDD isn't about the tools, it's about the conversations. I wrote a blog post to address the kind of things you're talking about: lizkeogh.com/2011/03/04/step-away-from-the-tools - hope it's of interest.
    – Lunivore
    Nov 15, 2011 at 22:08
  • @Mark Trapp: Thanks, Mark. I've edited my post accordingly.
    – Jim G.
    Nov 15, 2011 at 23:01
  • @Lunivore: Just curious - Do you write BDD tests or do you tell others to write BDD tests? I've found that project managers often fall in love with BDD. Unfortunately, BDD often falls apart at the altar of practicality.
    – Jim G.
    Nov 15, 2011 at 23:18
  • I'm a dev. I wrote the core of JBehave plus two automation tools, and have written many BDD tests myself. There are ways of making the tests easier to maintain - usually by getting the steps at the right level of abstraction. It really helps to have conversations drive this. The biggest problem I see is that devs don't always do this and sometimes dive straight into the tools, often because they're not co-located with business or testers. Bingo - your tests will be a mess. BDD falls apart if you don't have conversations.
    – Lunivore
    Nov 16, 2011 at 11:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.