Interesting questions about Behaviour-Driven Development

Question

For my master thesis at Software Engineering, I want to investigate in the new development technique BDD (Behaviour-Driven Development). In my opinion this technique could really improve on customer satisfaction, code coverage and bugs because of the force of executable specifications and the customer-understandable language.

For my thesis however, I struggle with the way I am going to validate that BDD could work better in certain circumstances. At the company I work during my study, work is still mostly done in a traditional, iterative way, where it sometimes is hard to change requirements after the requirements elicitation stage.

My question is, are there any people who already did projects with BDD, what are their experiences and have you ever felt something about BDD that you would want to investigate in, commencing on the above paragraphs? This could help me a lot with constructing my research question. Thanks in advance!

Answer 1

BDD is actually TDD with fixed terminology (see here).

BDD wiki provides a clear explanation. If done right, it can work quite well. At least it worked very well in my team when we switched from almost cowboy coding. The code coverage increased, and with it, the number of bugs reduced, and quality increased.

What is also good about it is that you automatically get YAGNI, KISS and if done right SOLID.

---

how the output of a new development technique like BDD can be validated?

As other development methods, BDD is not a silver bullet (such thing still doesn't exists in the software development). If after some time you do not see improvements in the code quality, then it's better not to use it. Under code quality, I mean : less bugs, easier to implement change requests, etc.

Answer 2

I think it would be a very valuable contribution to validate / test the premise that BDD leads to a leaner, more user-oriented test suite.

Codebases become very difficult to evolve over time in part because it is difficult to differentiate accidental complexity from domain-driven exceptions. That is, when one looks at a piece of code that seems like it could be refactored to be more simple, one has to consider the very real possibility that the complexity derives from some domain rule. ("Can we refactor foo->bar->bat->baz to get rid of bar or bat?" "Gee, we must have bar and bat for some reason!")

In a modern codebase, we expect that that all this complexity is exercised by test code. The instant we delete bar or bat we expect the suite to break, not just bar and bat, but foo too, since it's dependent. The premise of BDD is that you have user-meaningful frames that show that bar is low user-value, bat is associated with more value, and foo is very high, so, theoretically, you should be able to say "Well, we have to restore every foo test to green, we have to get these bat behaviors back, but we can lose bar entirely."

But is that really how it works? Or do BDD test-suites just devolve into a thin cover of "As a user of foo I expect the bar to be valid?" (testing the implementation rather than the user-valuable behavior)?

Answer 3

It will be difficult to do statistical analysis on the difference between two development methodologies. It's possibly beyond the scope of a Phd let alone a masters thesis.

One thing that could be interesting is a deep dive on a specific deliverable. For instance, how does the estimate (or test plan) differ in each? If you keep it manageable you may find a way to convince your boss to try a baby step too.

Answer 4

First understand that Behavior Driven Development (BDD) does not equal executable specifications in customer language.

Behavior driven development is equal to test driven development (TDD) in behavioral language.

TDD/BDD can yield great benefits to design, code quality, etc, if done pragmatically by BDD experienced developers.

Executable requirements can also yield benefits, but this depends more on your relationship with your customer, the nature of the product, and the organization.

Answer 5

> (...) have you ever felt something about BDD that you would want to 
> investigate in (...) ? 
> This could help me a lot with constructing my research question. 

When usig dotnet-specflow i found it difficuilt to keep track of reusable step/action-method definitions and correspondig textfragments. For me it feels like having software with many global variables and methods.

May be your research can cope with organising these?