6 Answers
6

a strong benefit i see in TDD and BDD is, that you have to clarify your requirements. a thing i often see with non-BDD, are unclear or even contradicting requirements. BDD 'forces' you to write them down and thus think them through, before writing any line of code. i've seen non-TDD code taking several turns, and a lot of YAGNI, because of changing or unclear requirement. you can avoid that and safe you some trouble by writing down the requirements first as a runnable test/feature.

First off, let me add a little clarity. BDD is not exactly TDD. A lot of people confuse the two because they both start with the concept that you write tests before you code. BDD has been described as "better TDD" or "doing TDD right", but I'm not sure that really applies either. Personally, I consider BDD as a Refocused TDD.

The idea is that you are able to do a number of things that many other approaches sometimes struggle with, and these are some of the advantages that you are probably looking for:

Your test code captures all of your requirements in a human readable form. I'm not just talking about method names and cleverly factored code, but instead the use of a good BDD framework allows you to write your tests using the language of the feature or story text you would have written down in a requirements document. (Look at something like StoryQ for dotNet as an example).

Your test code actually ends up testing to your requirements. If you write your test in the language of your feature specification, your end up testing to the specifications directly.

Test output reads like a report. Most unit testing scenarios result in a bunch of lights or onscreen flags to indicate pass or failure, but you get very little idea where the actual error has occurred beyond the approximate place that it was triggered. BDD output provides you with failure information regardless of whether the failure occurred in the execution of the code, or in the setup parts of your test, which leads me to the next point...

Your test code becomes highly granular, allowing you to more easily pinpoint the nature of failures in your tests/code.

Continuous live feedback through your tests means that you tend to work a little more efficiently, especially if you are applying a Test Driven process rigorously. Personally, I write all of my tests before I start to write any code. IT's a kind of up-front design without getting too tied to anything specific, and easily refactored if I change my mind later on.

For what it's worth, I use BDD regardless of whether it's at my job, or on my own side projects at home. I'm slowly converting others in my workplace to this approach, because I am able to show the advantages in terms of my productivity, and the lovely side-effect of having cleaner and more readable tests, and by extension cleaner and more readable code - although that last bit is not implied as a BDD benefit, but just to show you that I personally found myself leaning more in that direction.

I treat BDD as a way of reasoning about a problem from the perspective of the value a feature or similar will ultimately provide.

The basic premise of TDD was essentially a pattern or process for doing testing: write just enough test code to fail the test, write just enough code to make that test pass, refactor, repeat. It focussed on how, not why. In that light, I find BDD more useful, as it forces people to think about why they're even testing at all, and what net benefit -- what useful behaviour -- will be provided by their code once those tests pass.

BDD is just integration tests. That theyes may be writable by non-devs is a big draw, but incidental if there's nobody but the devs. That they're readable by non-devs, particularly the output, is a pretty big deal, since that ends up being a run-down of what the system can and cannot do, and what kind of expectations the system has.

So you're basically asking "do I really need to test that my whole system works," which hopefully you know the answer to.

I would say they are much more than just tests - acceptance criteria written in a BDD framework such as Cucumber can also act as a specifications, documentation or a contract.
–
Andy WaiteSep 28 '11 at 21:37

Still just tests--as I said, that they're readable and writeable by humans is a big deal and ends up being a human-parseable specification. Ultimate, still tests.
–
Dave NewtonSep 28 '11 at 21:38

3

The problem with referring to them as tests is that people tend to write them as test scripts, "go here, click that, fill in this...", instead of specifications which describe the actual business rules. (There's actually a discussion on the Cucumber list are present on whether to drop the web_steps.rb helpers entirely, as they are seen to encourage bad practice.)
–
Andy WaiteSep 28 '11 at 23:15

@Andy Waite: ...Acceptance criteria written in a BDD framework such as Cucumber can also act as a specifications, documentation or a contract. - Sure. They can; but they rarely do.
–
Jim G.Nov 15 '11 at 18:23

Nice link, but it doesn't really answer the OP's question. Methodologies in and of themselves only offer value if developers learn to sift through to what it is they really value, and what works for them and the teams they interact with. In my present job, we don't strictly do a specific methodology per-se, but we do use many of the concepts described in other methodologies to enhance our own. As far as BDD is concerned, it isn't strictly a methodology, but rather a tool or a practice that can be used to enhance an existing development process.
–
S.RobinsDec 14 '11 at 23:00

You are right - the answer I intended was "nothing" but I forgot to really say that. :)
–
jherikoDec 15 '11 at 17:22