In every Website you read about BDD (Behaviour Driven Development) you find a very simple nice example showing you how obvious and easy is it to define your requirements. But trying to implement this process in a big product (not a calculator example) showed me that things can get (or will get) pretty complex and unreadable; especially changing requests at a later point means a lot of work to correct the Integration tests for this.

So I'm wondering, is BDD really worth it? Does it solve a problem that other techniques don't!

  • Too bad, i think this issue is pretty constructive considering that BDD is beeing more popular lately.
    – D.D
    Feb 22, 2013 at 12:23
  • 1
    If anyone with enough rep can suggest a reopen it would be great guys.
    – D.D
    Feb 22, 2013 at 12:42
  • I would re-open, but you already accepted the first answer...
    – MattDavey
    Feb 22, 2013 at 12:58
  • 1
    I accepted because it was closed, so i knew no more answers were possible, but im really interessted in more experience reports on this, i'll unaccept it for now
    – D.D
    Feb 22, 2013 at 12:59
  • 2
    ok great :) I think also you should edit the question a little. I think your question is about the scalability of BDD in large projects. "Is BDD really that good" is subjective, "Does BDD scale well to large projects" is a little more objective.
    – MattDavey
    Feb 22, 2013 at 13:03

5 Answers 5


I think one of the best resources on BDD is Specification by Example book. It tells a lot about how to organize BDD tests and how they should be written so that they don't cause so much rework when requirements change.

If things get complex or overcomplicated in your tests then probably you are doing something wrong. It is same with BDD and TDD. Writing good tests is hard and it takes months to learn it.

  • 3
    TDD isnt the same, testing a predefined unit can never get that complex unless you have too big units wich is a code smell, but Integration tests are supposed to test the interaction between more than one unit, a total functionality, this let its complexity increases linear to the requirments, still you can not break it in smaller pieces since it wouldnt be inegtration test any more if done.
    – D.D
    Feb 22, 2013 at 13:47
  • You could attach some complicated BDD tests and I could see what can be done to make them simpler. Feb 22, 2013 at 13:49
  • Its not that easy, the ones i have here are not in english i would have to translate them, if ill find a requirment which i can easly translate to english i may attach it, but still the code behind is an issue too which would be too large to attach here in one post.
    – D.D
    Feb 22, 2013 at 13:52
  • Why was this downvoted? I gave great resource that will help OP solve his problems. Feb 22, 2013 at 13:54
  • that wasnt me, i will give +1 to compensate but i can do this only in 14 hours as i used all my 30 votes for today.
    – D.D
    Feb 22, 2013 at 13:57

It might help to realise that BDD's focus is the conversations. BDD is really an analysis tool which happens to provide some regression testing as a nice by-product.

I've used scenarios at all kinds of levels in conversation; from identifying different stakeholders to see if a release is likely to be well-received, to working out how a module or class should behave.

There are a couple of hints and tips I can suggest for making this easier.

If you've never done it before, it's going to change.

Anything which is new to the domain, or the business, is likely to change. You might realise you're in this space if you're talking through the scenarios, questioning them, and the business say, "Oh, I'm not sure." That's a good sign to stop trying to do BDD and spike something out to get faster feedback, to help the business work out what it is they want. Once the ideas have stabilized, scenarios can be written in retrospect.

All projects have some aspect to them that's new, or you wouldn't be doing them.

If you've done it before, it's boring.

As well as new, differentiating aspects, projects usually have some commoditised aspects to them which are similar to those already done. For instance, if I was producing a new mobile phone, it would still need to make calls. "Make a phone call" is such a well-known scenario that we wouldn't need to talk through it. Similarly, things like "login" or even "user registration" are boring.

Wherever possible, use libraries for these, and then you won't have to write scenarios around them. Also, do the other bits first - have an already-logged in user and work out what he's logging in for. These areas are unlikely to change, so you may be able to get away with manual testing anyway.

If someone has done it before, talking through scenarios can help.

There's a bit between where we have domain-specific requirements, stuff which is relatively well-understood by someone, and where the real uncertainty is mostly around scope rather than the actual behavior of the system.

Talking through scenarios can help the dev team to discover behavior, to draw on an expert's knowledge, and to ensure that the known, valuable behavior is captured.

This is the bit where BDD works best. My tip is to write the most interesting scenarios at the top of the feature file (or wiki, if you're not automating) and delete any scenarios which are duplicated or easy to infer as a result.

Wherever possible, use the scenarios just as examples of how the application works. For instance, if you want to show how validation works, show a couple of examples of how the application helps the user fill in a form. Check that validation is rigorous using unit testing, which is much easier to maintain and quicker to run.

Further reading

If you're interested in this, here are some things I wrote which might help.

BDD in the large

Cynefin for devs, which goes into these three areas in more detail

My tutorial slides, which are all nice and annotated for you, and cover the whole stack too.

  • Thank you for this informative answer, ill read the links you attached
    – D.D
    Feb 26, 2013 at 5:30

We built a fairly complex (domain complexity) project last fall and I can honestly say putting the up front work into BDD saved the project. I've seen a strong correlation between the domain complexity and the benefits of BDD.

Let me get one thing out of the way: testing complex business rules is hard. The question is, do you want to try and remember all the crazy scenarios whenever you make a change, or do you want that safety net to let you know when you've broken the spec. Spend the up-front time and work out all the scenarios, write them down, and eventually write all the tests for them.

And when you come back later trying to make sense of things, having that testable spec is a life saver.


BDD is a development process based on TDD (Test Driven Development) Here are some of the pros and cons of TDD drawn from my personal experience:

  • TDD, makes sure that your scope is well defined. This way, you design your test cases first. Thereby set an expectation for the piece of code you are supposed to write.
  • TDD is a way of safeguarding your code. Assume you write a simple function and then later you add some complex switching condition in this same function. Tomorrow, if someone else wants to modify this function, he can refer to the test case. If he wants to change your function, then, he has to change the test case too (most of the times). This allows him/her to understand that there was a reasoning behind what you wrote.
  • TDD allows for a faster software development. Each of us would have faced this issue while coding. We start off with an idea. And slowly lose track of it. We end up putting unwanted pieces of code to handle some scenarios. In TDD, you set the expectations upfront. Thereby, you restrict yourself from wandering off too far from the objective.
  • TDD allows you to catch possible bugs before the project goes online. This has mainly got to do with the quality of the test cases which are written.


  • At first, TDD can be a bit tricky. Many people dont understand the concept of a test case driving development.
  • TDD, sometimes can lead to huge efforts in maintenance. This has got to do with unwanted, or meaningless test cases.
  • TDD has to be taken with a pinch of salt. No developer likes spending time on some test case written by someone else. Deciphering the meaning of the testcase might sometimes cause a major headache.

I work on a project with more than 900,000 lines of code. And I still follow BDD.One major thing you need to consider is the number of the possible errors you might catch purely due to the test cases. A few years down the line, you'll be swearing by BDD!

  • 2
    You should elaborate more on the differences between BDD and TDD and where the DDD part comes in. Feb 22, 2013 at 12:01
  • 1
    @BenjaminGruenbaum Ideally, there is no difference between BDD and TDD. BDD when followed properly is same as TDD! So I didnt' see any reason to bring in the difference as a part of the answer. Thanks for the suggestion though! Feb 22, 2013 at 12:24
  • 2
    I haven't seen studies that show that "TDD allows for faster software development". But I have seen studies proving it is slower. Microsoft, IBM and I think Xerox did this exercise. Their studies showed 15-30% longer development time. But also a 40-90% decrease in bugs. Feb 22, 2013 at 13:40
  • 2
    @AlexandreMartins Hah, absolutely! Much more important to recognise that you might have poor quality tests & scenarios than to pretend they're all good IMO.
    – Lunivore
    Feb 27, 2013 at 11:49
  • 2
    @Lunivore Yes that's what bothers me in case of BDD/TDD. The test cases need to be strong. Unfortunately there's this view in the development community that as long as there are test cases, it's fine! I once saw a test case where there was a row being inserted into a table using a sql statement and the same being asserted on the very next step! Was the developer trying to test oracle functionality?! Mar 13, 2013 at 5:35

I have been implementing BDD for a large, complex project for more than 2 years now. Though implementing BDD is complex, we wouldn't have survived without it. There are several things to consider before you roll out BDD. Here are my lessons learned:

  • Collaboration: BDD is not an Automation tool or a Testing tool. BDD is about collaboration and keeping cross functional members of the team, mainly the 3 amigos, on the same page through the scenarios that are written in plain English or in the native language that the team is comfortable with
  • Parallel Run: Consider running your tests in parallel from day one
  • Templating: Consider templating your test messages (JSON or XML messages). This will save considerable time, as and when the application changes
  • Define standards: Use business language when writing Features
  • Good coding standards - Follow the same coding practice as functional code
  • Cultural change: BDD will work really well only if the entire team buys into it

You can see more on this in this blog https://blog.nocodebdd.com/lessons-learnt-in-automating-behaviour-driven-development-bdd-for-a-large-project/

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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