Remember: Cucumbers are fruits, not vegetables. And businesspeople are suits, not programmers. For two years, the Cucumber project has sought to change that.
Originally created by Aslak Hellesoy as a rewrite of RSpec’s Story Runner tools, Cucumber has matured enough for enterprise work. But can the suits be taught to use it properly?
The idea of plain-English requirements gathering tools is nothing new. Both Ravenflow and ThoughtWorks offer similar takes on requirement tools. Cucumber’s take on the idea comes from the behavior-driven development world, however, and focuses on taking the task to the businesspeople inside their comfort zones.
But Ryan Smith, software developer at consulting firm Entryway, thinks that this is a nigh impossible task. “In all fairness, I don’t think the intention was ever for businesspeople to be writing these, although they kind of marketed [Cucumber] that way,” he said.
“They should have correctly said it’s easy enough for people who don’t know code to write this, because it’s English. It’s not code. I work on a project where I did have a client try to write requirements in Cucumber. That was an experiment we did for a week, and it didn’t turn out well. I stopped doing that altogether.”
Smith feels it’s better to gather requirements in person, then build the code from those spoken and written cues, rather than rely upon the businesspeople to write requirements in a special subset of English.
Overcoming people problems
Joseph Wilk, a contributor to the Cucumber project, said that many of the problems traditionally associated with getting technical contributions and buy-in from business folk can get in the way of successfully using Cucumber.
“There is more to this problem than just tools,” he said. “If there is a people problem with businesspeople not wanting to engage in writing specifications, forcing a tool on them may be the wrong way to approach the solution and something Cucumber can do nothing about.”
But as a Ruby developer, Smith sees little value in adding Cucumber to the requirements process. He said that using it adds another step to his development tasks.
“Most Ruby developers find Ruby because they enjoy the syntax,” he said. “They enjoy expressing their thoughts in Ruby. [Yukihiro Matsumoto] created the language to be beautiful and to be a pleasure to work with. When I come to a project for writing tests, I love Ruby, so I feel more productive in Ruby. When I’m writing my tests in Ruby, I enjoy all the benefits of Ruby. When I write them in English, then I add another step to translate them to Ruby.”
But Wilk went on to say that Cucumber offers a way for developers and business users to speak a common language, and that’s a core principle of behavior-driven development.
“By having a specification/feature written in the business language that is driving development, we can help ensure everyone is speaking and thinking in the same language, and that the ubiquitous language is being pushed down into the code,” he said.
“Developers do have to interpret [business users’] needs, but how does the developer know that their interpretation is accurate?” Wilk continued. “At some level of discussion, there needs to be a shared understanding of what a feature needs to do. Nothing is better than sitting down and talking with the various stakeholders or exploring the requirements through examples/scenarios. Cucumber provides something that can be used in the exploration or as its output.”
He added that Cucumber documents can be revisited throughout the development process, as an unambiguous, plain-English way of describing what the software needs to do. “It’s also important to realize that Cucumber features persist as living documentation in the codebase,” he said.
Wilk said Cucumber-encoded requirements can be translated into tests later on, and thus it provides a medium for keeping the requirements close to the code throughout the life cycle.
