Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?
share|improve this question

migrated from stackoverflow.com Nov 15 '11 at 17:27

This question came from our site for professional and enthusiast programmers.

    
Possibly a partial duplicate of programmers.stackexchange.com/questions/43095/… –  Anna Lear Nov 15 '11 at 17:34
    
Binary decision diagrams? –  Peter Taylor Nov 15 '11 at 19:56
    
One of your problems (with finding big names) is that BDD may be considered a competitive advantage so not necessarily shouted about. Another is that in a big company there may be teams doing it and teams not. –  Murph Nov 16 '11 at 8:13
add comment

2 Answers

up vote 2 down vote accepted

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.

share|improve this answer
    
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. –  Mark Chidlow Nov 17 '11 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 '11 at 10:25
add comment

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.

share|improve this answer
    
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 '11 at 22:08
    
@Mark Trapp: Thanks, Mark. I've edited my post accordingly. –  Jim G. Nov 15 '11 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 '11 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 '11 at 11:01
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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