wood burning stoves 2.0*
The moose likes Design and the fly likes Benefits/Advantage of BDD? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Engineering » Design
Bookmark "Benefits/Advantage of BDD?" Watch "Benefits/Advantage of BDD?" New topic
Author

Benefits/Advantage of BDD?

Fei Ng
Ranch Hand

Joined: Aug 26, 2000
Posts: 1242
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.
Burk Hufnagel
Ranch Hand

Joined: Oct 01, 2001
Posts: 814
    
    3
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


SCJP, SCJD, SCEA 5 "Any sufficiently analyzed magic is indistinguishable from science!" Agatha Heterodyne (Girl Genius)
B. Katz
Ranch Hand

Joined: Aug 28, 2009
Posts: 51

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.


"I do not feel obliged to believe that the same God who has endowed us with sense, reason, and intellect has intended us to forgo their use."
-- Galileo Galilei
Burk Hufnagel
Ranch Hand

Joined: Oct 01, 2001
Posts: 814
    
    3
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.

Marco Emrich
Author
Greenhorn

Joined: Aug 14, 2013
Posts: 20
    
    5
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

Joined: Oct 01, 2001
Posts: 814
    
    3
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
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: Benefits/Advantage of BDD?
     
    Similar Threads
    BDD framework
    Why learn Ruby ? what's the benefits over other languages ?
    author and the TDD experts, whats your opinion on BDD/TDD?
    Clean Code: TDD and BDD
    Behavior-driven testing