• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Benefits/Advantage of BDD?

 
Ranch Hand
Posts: 1246
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Is BDD a must nowadays? Does it speed up developing time? From what I am seeing BDD takes a lot of time before you even write a single line of code. What if the requirements/Behavior changes? Do you start all over again? And BDD looks a lot like TDD which is confusing.
 
Ranch Hand
Posts: 883
3
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Fei Ng wrote:Is BDD a must nowadays?

I don't know if it's a must, but I would certainly consider it a Very Good Thing to do since it gets the business, developers, and QA to agree on what the program is supposed to do and how we'll know it's working properly.

Fei Ng wrote:Does it speed up developing time?

Probably. Since the business, devs, and QA have agreed on what the program is supposed to do, including how it will respond to given events, there's less confusion over requirements and should be fewer bugs. You also know if the code you're writing contributes to meeting the requirements or not, so there's less "Gold Plating".

Fei Ng wrote:What if the requirements/Behavior changes? Do you start all over again?

No more so than you do now. Probably less since the time spent working with the business and QA to decide how the program is supposed to respond to different events and inputs tends to make them think more deeply about what they want. This tends to reduce the chances of requirement changes.

The Good News is that even if there are changes to the requirements or behaviors, modifying your BDD code to match the new expectations will show you just where the breakage is, and when it is fixed again.

Hoping this helps,
Burk
 
Ranch Hand
Posts: 58
MyEclipse IDE Chrome Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Greetings,

I think I would have to agree with Burk on this.

While I am new to BDD and it's implementation, I have been subject to the whims of the proverbial "moving target" project spec and the victim of project creep.

Getting all parties that have their own idea of what the application should look and feel like to sit down and all agree on one specification should cut down the common "Oh, no! We already promised it *this* way to the customer..." statement from ever coming up, hence cutting down on you having to go back and rewrite entire sections of the app you *just* finished!

HTH. Let us know.
 
Burk Hufnagel
Ranch Hand
Posts: 883
3
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

B. Katz wrote:Getting all parties that have their own idea of what the application should look and feel like to sit down and all agree on one specification should cut down the common "Oh, no! We already promised it *this* way to the customer..." statement from ever coming up



Thanks, B. My worst favorite was being told, "I know we said X, but what we meant was..." -- after the code was tested, debugged, and ready for delivery.

 
Author
Posts: 20
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Fei,

Burk and B. Katz already covered the most important aspect: BDD is mostly about communication! - therefore, reducing misunderstanding and rework. I absolutely agree with that.

I would like to add, that TDD is still a big part of BDD. BDD just changes the vocabulary a bit. Testing sounds like an afterthought, Specs have to be written beforehand

BDD also doesn't need to take a lot of time before your first line of code. You usually do a specification workshop with the team, to gather some requirements. But you need these requirements anyway and writing two or three specs to get you started shouldn't take you more than several minutes. You only need some high-level specs and shouldn't fixate them all upfront. Meeting and talking often is the key, like in all agile processes.

Marco
 
Burk Hufnagel
Ranch Hand
Posts: 883
3
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Marco Emrich wrote:I would like to add, that TDD is still a big part of BDD.


Marco,
I forget where I saw it, but someone has a diagram that shows BDD as part of an expanded TDD cycle. Rather than:
  • Write a test that fails
  • Watch it fail -- a critical step, many people forget
  • Write the code to make the test pass
  • Refactor the code -- another often skipped step

  • You get something like this:
  • Write the specifications
  • For each specification
  • ___Watch it fail
  • ___Write the unit tests needed to make the spec pass, using the TDD cycle from above
  • Go to the next specification.

  • Marco Emrich wrote:Testing sounds like an afterthought, Specs have to be written beforehand


    Agreed. The trick about writing tests is to do them first - otherwise you've got to fight the feeling that you're wasting time writing tests for something that you "know" works. The other problem with writing tests last is that unless you've had some practice, it's not uncommon to find that the code you want to test isn't very easy to test. However, if you write the tests first, then you're forced to write code that can be tested - which, as Uncle Bob Martin points out, tends to be cleaner and easier to understand too.

    Burk
     
    Consider Paul's rocket mass heater.
    reply
      Bookmark Topic Watch Topic
    • New Topic