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.
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,
SCJP, SCJD, SCEA 5 "Any sufficiently analyzed magic is indistinguishable from science!" Agatha Heterodyne (Girl Genius)
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
Joined: Oct 01, 2001
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.
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.
Joined: Oct 01, 2001
Marco Emrich wrote:I would like to add, that TDD is still a big part of BDD.
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.