Hi Albert. Great writeup. I agree with many of your points. Having tried to implement BDD with 8 to 10 sprint teams across the globe for the past 2 years — BDD has a lot of overhead. The biggest benefit really is the upfront conversations. If the team is only going to use BDD as an automation framework that is really when the issues begin. Also if you have many teams that don’t agree on the DSL that will be used by everyone there tends to be lots of duplicated G/W/T.

I’m certainly /still/ interested how to “wow”. With the crew from Toronto Testing Meetup we recently took a close look at BDD practices, and the results were mixed. (Experience report: http://automation-beyond.com/2016/06/10/roundtable-on-behavior-driven-development/)

While we all agreed that it is a rewarding social process to discuss requirements and implementation together, practicing with Gherkin scenarios uncovered many downsides.

I’m interested in collaboration with BDD practitioners to address the discovered problems. Can you recommend / invite someone?

Thank you,
Albert Gareev

Hi Rob – I completely agree. Hope that is now what you go our of this article. TDD and BDD are a great way for teams to collaborated an uncover bug before code is written. Will it catch “ALL” bug NO but it will catch many more then if teams are not collaborating and communicating with one another to make sure they understand what is the real requirement and what Risk they need to watch out for.

The idea that either tdd or bdd can contribute to ‘defect free software’ is clearly incorrect. In fact ‘defect free software’ is not feasible except possibly in the most simplistic of programs and even then I’d argue it’s still not possible.

Rob