There have been a couple of articles published recently by Nikolay Advolodkin (SDTimes and SauceLabs) that use a straw man argument to critique Behaviour-Driven Development (BDD). BDD is not test automation -- it’s collaborative requirements analysis combined with test-driven development (TDD), which despite the name, isn’t testing either.
Previously…
This is the fourth in a series of articles digging into user stories, what they're used for, and how they interact with a BDD approach to software development. This post is the last in this series, but certainly not the last time I'll be talking about user stories. However, since it brings the current narrative arc to a close, it is perhaps the end of the beginning.
This is the third in a series of articles digging into user stories, what they're used for, and how they interact with a BDD approach to software development. You could say that this is a story about user stories. And like every good story, there's a beginning, a middle, and an end. This post is a continuation of the middle.
In the first post in this series we introduced the concept of the Screenplay pattern and busted a couple of popular myths about it. Now it's time to start digging into some code to give us a real example to demonstrate the pattern on.
The problem with writing this kind of tutorial, always, is finding the right balance between an example that's so complicated it gets in the way of your understanding the thing we're actually trying to learn about, and one that's so simplistic that the need for any kind of software design seems superfluous. If you'll forgive me, we'll err towards the simplistic here, and I'll trust that you've seen enough complex code in the wild to recognise the need for some design work.
This is the second in a series of articles digging into user stories, what they're used for, and how they interact with a BDD approach to software development. You could say that this is a story about user stories. And like every good story, there's a beginning, a middle, and an end. Welcome to the middle!
Once you've decided to invest in test automation, sooner or later you'll begin to realise that you need to care about the maintainability of that test automation code just as much as you do about the implementation code itself.
For acceptance tests this problem is particularly acute: driving the application from its outside edges involves connecting to APIs, databases, web UIs etc., and this code can quickly get out of hand. Having tried several different approaches myself over the years, I've come to believe that the Screenplay pattern is the best technique we have today.
But it doesn't get the attention it deserves.
This is the first in a series of articles that will take a look at user stories, what they're used for, and how they interact with a BDD approach to software development. You could say that this is a story about user stories. And like every other story, it's important to choose where to begin – because, contrary to the advice given in the Sound of Music, it's not always a good idea to "start at the very beginning".
We recently ran a survey as part of the work to bring Cucumber into the SmartBear and HipTest family. It was a quick sample (189 responses collected in under a week) rather than in-depth research, but it yielded a couple of interesting indicators that I want to share.
This was originally posted on Matt's personal blog.
Barbara is a business analyst.
Until recently, Barbara hated BDD.
This was extracted from BDD Books 2 - Formulation by Seb Rose & Gáspár Nagy.
Over the past few years, there has been a growing recognition that BDD is an approach made up of three practices.
During Discovery, the team will capture concrete examples of how the system is expected to behave. While doing this, they will also uncover important business terminology. Formulation is the process of transforming the concrete examples into business-readable specifications that will guide development and document the product for its whole lifetime.
Who should formulate the scenarios?