COOL AS A CUCUMBER

Behaviour-Driven Development for the Modern JS Developer

Colby Chiste, a Software Developer at Acro, explores behaviour-driven development in the modern JavaScript environment. Discover how these technologies streamline coding and bring a new level of precision and understanding to development projects.

Introduction to Behaviour-Driven Development

Behaviour-driven development, or BDD, can be a contentious topic; let’s just get that out of the way. 

“Behaviour Driven Development (BDD) is a synthesis and refinement of practices stemming from Test Driven Development (TDD) and Acceptance Test Driven Development (ATDD). BDD augments TDD and ATDD with the following tactics:

• Apply the “Five Why’s” principle to each proposed user story, so that its purpose is clearly related to business outcomes
• Thinking “from the outside in”, in other words, implement only those behaviours which contribute most directly to these business outcomes, so as to minimize waste.
• Describe behaviours in a single notation that is directly accessible to domain experts, testers, and developers, so as to improve communication.
• Apply these techniques all the way down to the lowest levels of abstraction of the software, paying particular attention to the distribution of behaviour, so that evolution remains cheap.”

Source: Agile Alliance

Implementing BDD: Not As Easy As It Sounds

Do a quick Google search, and you will find common threads of “we tried this, and it went terribly” that, without fail, feature replies informing them that they aren’t doing it correctly. Success and failure stories abound, and fair points come from both sides. 

Project cohesion can degrade as teams change or as a project grows. When I first faced this reality, I had a few emotions to sort out. 

• Frustration that I hadn’t documented better from the start
• Confusion and uncertainty about the more complicated user flows in our application
• Lamentation about the loss of product knowledge

These feelings spurred me to find some sort of solution and is how I started looking into a way to implement behaviour-driven development in a practical fashion.

---

Biting into Cucumber

Looking into popular frameworks (and having just read The Clean Coder: A Code of Conduct for Professional Programmers), I, of course, came across Cucumber.

 “Cucumber Open is the world’s leading tool for BDD. Work faster and smarter than your competition by supporting a team-centric, cross-functional workflow.” - Cucumber.io 

After learning their syntax was based on and named after the Gherkin DSL, that’s all I had to know to dive in. 

“Just going to hammer out some Gherkin,” “There’s something wrong with my Gherkin,” the comedic potential was astounding.

For our use case, I chose the Cypress Cucumber Preprocessor package. If UI testing is unnecessary or Cypress is just too beefy for your projects, the alternate Cucumber.js as a command-line-only tool. However, I will not be covering the latter. 

With the Cypress Cucumber Preprocessor package installed, let's start diving in.

First, we must tell Cypress about the new plugin and when to run the plugin.

Don’t forget to update your Cypress configuration to include the new feature files.

Next, we will create the integration directory inside the Cypress directory if it does not already exist. 

This directory is where the preprocessor will look for your feature files. Gherkin syntax takes after BDD, so we know we will be breaking things out into “Given,” “When,” and “Then” code snippets. 

Let’s work through a simple example of updating a user's profile.

There! A fairly standard flow, testing the happy path for a profile update. 

However, our work is incomplete, as we have to convert and generalize these statements into cypress commands and assertions. 

Create a new folder structure in your cypress/integration/Cucumber directory; “common” will work as the root folder name for now.

Additionally, include a directory for “And,” “Given,” “Then,” and “When,” each under the common root. These are where our commands will go. 

Here are some examples to give you an idea of the types of interactions you can get between them.

And on and on until we have all the snippets needed for our feature/scenario. Then, when running Cypress, we can run everything all together or just Cucumber via 

---

Benefits of Using Cucumber for Project Success

Speaking to BDD in general, in an ideal scenario, there are a couple of benefits apparent: 

• Fleshing out requirements from stakeholders can be a fickle task, which is why stakeholder engagement and inclusion at the ground level of planning sounds so appealing
• Plain language tests help describe the system in the simplest terms, creating a sort of manual for stakeholders and technical staff alike

These, however, are only achievable with intense and consistent stakeholder engagement, which, for the majority of teams out there, is just not feasible. 

While I found the process of BDD to not be feasible for our team, the patterns that emerged from the exercise were thought-provoking. At the very least, the thought of reusable testing commands and assertions excited me. It was such a simple thing, yet I had never considered it.

This being said, even if you aren’t following BDD on your current team, it doesn’t mean you won’t ever be on one that will use it. 

Going through this exercise yourself will get you up to speed on the basics, and, who knows, perhaps you will pull something applicable out of it for immediate use.

Want to learn more about behaviour-driven development?

Fill in the form below, and one of our subject matter experts will reach out.