Skip to main content

BDD, approval testing, and VisualTest

Seb Rose
Co-author of The BDD Books

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.

BDD with Event Mapping

Jon Acker
Jon Acker
Senior Consulting Engineer at Armakuni, London

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.

Bringing feature context to your testing best practices

Trevor Stuart
Co-founder of Split.io

At Split, we believe the primary unit of work for software teams is the feature.

Feature flags are transforming the way we develop software. These sections of code govern the execution of a specific software feature, allowing that feature to be toggled on and off without a new deployment. Every tool we use to develop, test, and measure product changes must adapt.

Because of recent advances, feature flags allow releases to be more stable than ever. More teams are testing in production, as they are now able to roll back feature changes with the flip of a switch. Even with these advances, however, we still need to deploy best practices when testing our production changes, to protect users from a poor experience.

Webinar: Introduction to Formulation

Seb Rose
Co-author of The BDD Books

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.

Tackling structural racism and sexism in open source

Matt Wynne
Project Lead of Cucumber

One of the goals the Cucumber team have set ourselves this year is to increase the number of recent, regular contributors who are non-white or non-male from 0 to 2. This post describes why we want to do this, what we’ve learned so far about the systemic barriers that keep the community of people who contribute to open source so utterly imbalanced, and outlines how we’ve started tackling the problem in our own project.

How can Cucumber help us understand the root causes of failure?

Seb Rose
Co-author of The BDD Books

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.

  1. Why should automation be done by the dev team?
  2. Isn’t the business-readable documentation just extra overhead?
  3. What’s wrong with changing the scenarios to enable automation?
  4. Can all testing be automated?
  5. How can Cucumber help us understand the root causes of failure?

The question

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...?

Can all testing be automated?

Seb Rose
Co-author of The BDD Books

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.

  1. Why should automation be done by the dev team?
  2. Isn’t the business-readable documentation just extra overhead?
  3. What’s wrong with changing the scenarios to enable automation?
  4. Can all testing be automated?
  5. How can Cucumber help us understand the root causes of failure?

The question

Isn't the goal of repeatability for refactoring confidence, not test confidence?

What's wrong with changing the scenarios to enable automation?

Seb Rose
Co-author of The BDD Books

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.

  1. Why should automation be done by the dev team?
  2. Isn’t the business-readable documentation just extra overhead?
  3. What’s wrong with changing the scenarios to enable automation?
  4. Can all testing be automated?
  5. How can Cucumber help us understand the root causes of failure?

The question

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.