views:

982

answers:

4

Having written a small article on BDD, I got questions from people asking whether there are any cases of large-scale use of BDD (and specifically NBehave).

So my question goes to the community: do you have a project that used BDD successfully? If so, what benefits did you get, and what could have been better? Would you do BDD again? Would you recomment it to other people?

+2  A: 

I was on a small team that used BDD on a website.

The way we used it was essentially TDD, but the tests are simply written as behaviors using a DSL. We did not get into large upfront design of behaviors, but we did create a large number of them, and used them exactly as you would tests.

As you might expect, it worked much as TDD, generally good. Phrasing the tests as behaviors was nice when interacting with the customers and made for a pretty decent document, but I kind of wish the behaviors were written in English and the tests programmed instead of trying to come up with some difficult intermediate language that doesn't fit either purpose perfectly.

It would still be BDD, just without this cute trick of trying to twist the language into a language delineated by a random_looking.set of_Punctuation rather_than simple.spaces, but that was only my grumpy-old-programmer attitude, everyone else was 100% happy with it.

The site is available and fully operational, so I'd call it a success: Have a look

Bill K
+3  A: 

We've used somewhat of BDD at the code level in different scenarios (open source and ND projects).

  1. Telling the view in MVC scenario, what kind of input to accept from user (DDD and Rule driven UI Validation in .NET)

    result = view.GetData(
      CustomerIs.Valid, 
      CustomerIs.From(AddressIs.Valid, AddressIs.In(Country.Russia)));
    
  2. Telling the service layer, about the exception handling behavior (ActionPolicy is injected into the decorators):

    var policy = ActionPolicy
      .Handle<WebException>()
      .Retry(3);
    

Using these approaches has immensely reduced code duplication, made the codebase more stable and flexible. Additionally, it made everything more simple, due to the logical encapsulation of complex details.

Rinat Abdullin
+1  A: 

I recently used the BDD style of GWT in a high-level requirements document. I didn't get any feedback about the GWT from the customer buy my boss said he liked it as it was very clear and easy to understand. Note he has no knowledge of BDD that I know of. I didn't put in user stories as this would probably have been a bit too airy fairy for people with a traditional waterfall background. Maybe I'll try putting in user stories next time.

By the way this was not a eye ball UI project. It was an integration project syncing data from a web service into a database. So it shows that GWT works even for non-"eye ball" UIs.

Jonathan Parker
A: 

I've been using Context-Specification style on several projects (using MSpec) with great success. I am still trying to understand the real benefits of the Scenario style. The more I use the context-specification style, the more I like it, and the tighter my applications feel.

leebrandt