Cucumber is a simple tool. It takes phrases written in plain language, finds snippets of code that match those phrases, runs them, and tells you whether they threw an error.
How you organise the code that Cucumber finds, is up to you.
What you get that code to do, is up to you.
If your Cucumber suite is slow, or hard to maintain, that's because the code you've asked Cucumber to run is too slow, or too complex.
At CukeUp London the 3rd of April I gave a presentation of Cucumber Ltd - the company Matt, Julien and I have started. This post explains why we started the company, and how it will benefit you.
There are lots of names for the conversations we have to prepare user stories for development. Some people hold Three Amigos or Specification Workshops, some hold Planning Poker or Backlog Grooming sessions. Whatever you call this work, essentially you're trying to answer two questions:
These two questions form a dynamic: when a clearly-defined requirement turns out to be complex to build, developers and product owners can usually negotiate to find a simpler what that has a more straightforward how. Similarly, product owners may not be able to clearly define what they want until they've had a chance to have it examined by the people who will think about how to build it.
I recently watched a team having what they called a Sprint Planning meeting. For this team, that meeting was their opportunity to have this conversation. As they laid out the stories for discussion--each on 5"x3" index cards--I came up with a suggestion.
Cucumber reached a million downloads in the first three years and 5 million downloads 3 years later. I'm happy to have created such a popular tool, but saddened to see how it's misused and misunderstood.
If you think Cucumber is a testing tool, please read on, because you are wrong.
Cucumber was born out of the frustration with ambiguous requirements and misunderstandings between the people who order the software and those who deliver it.