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.

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.

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.

Cons:

• 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!

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/