At last month’s CukeUp conference, I held a panel discussion between Aslak Hellesoy, Julien Biezemans, Oriol Gual and Jonas Nicklas. I chose these panelists because each of them has written a variation on the original Ruby Cucumber, and I wanted to try to pull these ideas together into a vision for Cucumber 2.0.
This post is a record of that conversation.
Why do we need a new Cucumber?
The current version of Cucumber has been around since 2008, and as Jonas has previously explained the code isn’t much fun to hack on. It’s quite bloated with features, some of which were added as experiments and maybe aren’t used by most users. Carrying this cruft around is holding us back from adding new features that we do want.
Also, the current mechanism for mapping from steps to Ruby code is pretty basic, and doesn’t really encourage the good practices we’ve learned as a community about organising your test code.
What is your vision?
I asked each of the participants what they’d learned from their fork of Cucumber, and what they’d like to see in a new version of Cucumber.
Aslak made three points:
- It should be possible to use Cucumber as a library, so that other tools can be built on top of it as well as the command-line interface.
- The way steps are defined in Cucumber-JVM, by simply annotating existing methods, allows you to focus on keeping your test code well organised. We should steal this idea for Cucumber-Ruby.
- There should be a collaborative web UI for writing Cucumber scenarios with non-technical stakeholders.
- Integrating the Cucumber-HTML project, which is essentially a web-based client for Cucumber, would be awesome.
- It would be nice to use the Cucumber-TCK, which is growing into a standard set of specs for any Cucumber implementation.
- He hasn’t implemented calling steps from step defs in Cucumber-JS, and he’s not sure he wants to.
- Parallel execution – can we make this possible?
Oriol echoed Aslak’s thoughts about keeping test code better organised: Spinach uses one class per feature, and is generally more object-oriented unlike Cucumber-Ruby’s flat anonymous blocks for step definitions.
Jonas said his goal for Turnip was mainly simplification:
- He thinks that the reason some people had started to abandon Cucumber was to do with it being perceived as complex.
- Jumping from plain english steps to Regexps is jarring, and too big a leap in abstraction. 98% of the time you don’t need regular expressions anyway. Turnip uses the concept of placeholders in strings instead to capture arguments.
- Using RSpec as the runner for Turnip hasn’t worked out so well.
What features should we remove?
It’s always fun making a ‘not’ list, so we brainstormed the current Cucumber features we’d like to kill in a 2.0 release:
In case you can’t read my scrawl, here’s that list again:
- Wire protocol
- Calling steps from step defs
- Tables (we’re talking about scenario outlines here)
- DRB / Spork
- World having everything mixed in, all the time
- Given / When / Then being regarded as the same by Cucumber
As you can see, we got the audience to come up and vote after the session. It looks like nested steps are living on borrowed time!
My view is that with a well-designed core, many of these features can still exist but as plug-ins, thereby allowing people who need them to continue to use them, but without the maintenance burden on the core team.
So what’s next?
What I’m short on is time. Would it be crazy to ask if there are any companies who would consider sponsoring this project? I can’t imagine a better way to spend the summer than hacking out a brand new shiny Cucumber!
Update: Thanks for the comments, but I don’t find they make a great medium for discussion so I don’t tend to reply to them. If you’d like to discuss this post, please chip in on these threads on the cukes google group.