Cucumber: How, and Why, do we use it?

When writing Behaviour-Driven Development style tests, it can be incredibly difficult to get the right level of detail, technical level, and consistency in the test writing stage. Everyone who writes a Cucumber script will attribute their own meaning and structure to their test case, some using more technical jargon, some will take a more high level approach, but understanding how to write high-quality Cucumber scripts means a re-focusing on what is its purpose.

Official Documentation

SmartBear (the owners of Cucumber Studio) have a fantastic set of docs on Cucumber, and specifically the philosophy of what Cucumber's goals are, and what Scenarios should mean for an organisation, found here.

Cucumber == Documentation

When we're writing Gherkin statements, we are writing Documentation.

This is really important, because if we wanted to just write test cases and script them up, there are much easier and quicker ways to do so, especially considering that cucumber integration is an added complication for most popular tools, like Selenium, Playwright, and Cypress.

What does this mean?

When we start to think of writing feature files as writing documentation, we open up to the consideration of our target reader. We might consider this as the testers who typically write the Scenarios in many businesses, but in reality we want BDD to be a collaborative affair, involving technical and non-technical team members alike. Product and Customer Success teams should be able to view a feature file, and understand the functionality it covers, ideally being able to run through manually, replicating the tested functionality - even customers will be interested from an acceptance view, giving them the answer to the question, "Does this do what I want it to do?", preferably before you've spent development and test hours building and deploying the new feature.

In long-standing codebases, it can rapidly become about writing scenarios quickly, and generate quantity over quality, and so corners can be cut such as directly referencing variable names in a longer test, or in some cases I've seen, locator xpaths in a feature file!

How does this help?

With the above in mind, it becomes extremely valuable, and potentially cost-saving to develop feature files with non-technical readership in mind. It gives us another tool to really speak the language of our customers and provide quality services to them. There's even the added value of providing tested documentation of how a new feature should work, it's one of the best ways right now to see not only if something breaks but also how it impacts a user with minimal investigation.

Treating Cucumber as documentation also gives us the power to provide tested Demo User Journeys, we can use the files to educate new team members how a product works, and even what journeys are the highest value, or highest risk.

Overall, If we craft our statements in a way that our Customer Success and Product teams, Senior Management, Customers, and the Development team can follow, we bridge the gap between all these business sectors and begin working towards a collective goal.