I have found this lines below about the advantages of BDD (Behavior Driven Development)

The domain experts define what they need in the program in a way that the developers can not misinterpret (or at least not as much as in most other approaches).

Are there any more advantages apart from that?
If I'm working alone (I'm not in contact with managers that could write BDD features),
do I need to use BDD?

  • Is this question really specific to Ruby or Ruby on Rails? – Mike Partridge Nov 15 '11 at 19:16
  • Nice question, +1. – Chiron Dec 14 '11 at 22:16
  • BDD can be useful for a solo developer for two reasons, firstly it helps to keep the focused on the objective (can also be done with plain TDD), it helps to reflect the business domain naming conventions into the code, and finally in OO helps to make the code follow the tell don't ask paradigm, since it is top-down rather than bottom-up development. – Martin Spamer Oct 9 '18 at 17:03

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:

  1. 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).
  2. 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.
  3. 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...
  4. Your test code becomes highly granular, allowing you to more easily pinpoint the nature of failures in your tests/code.
  5. 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.



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.


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.


You say you're working alone, but it certainly sounds like you're writing code for other people, so there must be some communication of requirements going on.

Writing down acceptance criteria before starting a piece of work is just common sense. If you can then take that a step further and automate that, then great.

However, learning how to write acceptance criteria at a suitable level to be of interest to your stakeholders takes skill and practice.


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 Waite Sep 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 Newton Sep 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 Waite Sep 28 '11 at 23:15
  • Fair point; I can get behind that. – Dave Newton Sep 28 '11 at 23:30
  • @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

I'd ignore BDD as a buzzword and just get on with design/code. These methodologies are all so trivial you will re-invent it or come up with something better without making a conscious effort.

Also known as programming, motherf*cker

  • 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.Robins Dec 14 '11 at 23:00
  • You are right - the answer I intended was "nothing" but I forgot to really say that. :) – jheriko Dec 15 '11 at 17:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.