A year ago, Cucumber returned to community ownership. I'd like to take a moment to reflect on what we have been up to.

Today is a big day for Cucumber.

6099 days since the project was first started, 4158 days since we formed Cucumber Ltd, and 2004 days since SmartBear acquired Cucumber Ltd we have entered a new and exciting phase: Cucumber is back in community ownership.

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.

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.

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.

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.

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

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.

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?