This blog post explores the challenges of applying a Behavior-Driven Development (BDD) approach to UI development using VisualTest. In addition to giving a high-level introduction to BDD, I’ll describe a technique called Approval Testing that complements traditional assertion-based testing to give developers clearer visibility of the correctness of their implementation.
The original version of this post was published on Medium by The BDD Advocate.
The full spectrum of Behaviour Driven Development involves collaborative activities at both a high level, e.g. discovery workshops, and at a lower level — in terms of automating the discovered use-cases.
The discovery however, is sometimes the hardest part, making sure all the use-cases of the system are known and understood by all concerned: from the product owners, who know how the product should work, to the programmers who need to build the system to these precise specifications.
A couple of weeks ago, Gáspár Nagy and I presented a webinar on the BDD practice of formulation. There were so many questions that we were unable to answer them all in the allotted time, so we’re taking this opportunity to publish our answers as a blog.
We’ve merged similar questions together, so what you see below is a summary of the outstanding questions.
I’m continuing to answer questions that were asked during my session “Are BDD and test automation the same thing?” at the Automation Guild conference in February 2021. This is the last of five posts.
Specific about Cucumber reporting. I find that sometimes a single bug can break several Given-When-Then scenarios, which is great to measure business impact, but not great to understand root-causes/bugs. Any ideas on this? We ended up creating a complementary root-cause report...?
Seb Rose and Gáspár Nagy are the authors of The BDD Books. Cucumber Community Manager Tracey S. Rosenberg spoke to them about their books, the writing process, and what comes next.
I’m continuing to answer questions that were asked during my session “Are BDD and test automation the same thing?” at the Automation Guild conference in February 2021. This is the fourth of five posts.
Isn't the goal of repeatability for refactoring confidence, not test confidence?
I’m continuing to answer questions that were asked during my session “Are BDD and test automation the same thing?” at the Automation Guild conference in February 2021. This is the third of five posts.
Why many times I find myself changing the BDD statements once I start automation, as there is certain information needed between steps? BDD framework is supposed to involve many stakeholders and yet I feel the statements are to be written in a very stringent fashion.
After my talk called “Are BDD and test automation the same thing?” at the Automation Guild conference in February 2021 there were more questions than I could answer in the available time. This is the second of five posts answering the five most important ones:
Doesn't adding something like SpecFlow to interface with something like Selenium just add an extra code base that must be maintained? Does the benefit justify the extra work?
I’ve been writing and talking about test automation and BDD for quite a while now. In February 2021 I gave a short version of a talk called “Are BDD and test automation the same thing?” at the Automation Guild conference to explore their relationship and address the confusion that exists in the industry.
The conference organiser, Joe Colantonio, hosted a Q&A session after the talk, but there wasn’t enough time to answer all of the questions. Handily, he provided me with a list of all the questions asked, along with his estimation of their “sentiment” – either neutral or negative. In this series of posts, I am going to address the five unanswered questions that he marked as having a negative sentiment.
I do not get, why you say the automation part #5 on the graph, should be done by the dev team and never the QA, because it's part of the design process. For example, if a team uses Serenity-BDD with screenplay, which makes it very easy to implement SBEs, shouldn't dev team focus on prod code instead?
Recently my colleague, Theo England, broadcast a question:
We're thinking about running a … one-day class [about BDD] designed for business execs. Tell us the questions we must answer for it to be useful.
We received 60 responses, including some very good questions.
As well as providing valuable input into the design of our upcoming course, BDD for busy people, we felt that we should answer some of the questions in a public forum. This is the second in the series.
“Where does the sign-off of requirements happen – and how is it documented? Can we have full traceability?”