Comments on: A vision for Cucumber 2.0

By: Jamie

Jamie — Wed, 20 Mar 2013 15:49:41 +0000

I would say getting rid of calling steps from other steps is a good direction to go. It creates an inner dependency on step definitions that imo shouldn't exist. Instead creating easily readable method calls should be the more used practice.

By: Gary Taylor

Gary Taylor — Wed, 26 Sep 2012 17:38:41 +0000

-1 to killing calling steps from step defs - as I think someone else has mentioned, it allows the tests to be high level and the detail defined elsewhere, whilst keeping the detail visible to anyone that needs to know just what "When I login as a new user" really does.

By: A Smattering of Selenium #92 « Official Selenium Blog

A Smattering of Selenium #92 « Official Selenium Blog — Thu, 21 Jun 2012 16:01:42 +0000

[...] A vision for Cucumber 2.0 is rather interesting [...]

By: The Mega Ruby News and Release Roundup for May 2012

The Mega Ruby News and Release Roundup for May 2012 — Mon, 11 Jun 2012 15:17:51 +0000

[...] A Vision for Cucumber 2.0 Cucumber is a popular natural language accepting testing toolkit for Ruby and in this post Matt Wynne has collected together ideas from various Cucumber maintainers to see what's coming in Cucumber's future. [...]

By: Tatiana

Tatiana — Tue, 15 May 2012 20:53:12 +0000

I think not allowing step defs to call other steps is showing limited vision for how Cucumber can effectively be used.

Even if some peole personally don't like the practice, there are many of us that use this technique to what we consider good effect.

By: Matt Van Horn

Matt Van Horn — Fri, 04 May 2012 00:42:56 +0000

I love using Regex in my steps, mostly so I can have one step cover a bunch of related conditions e.g.

Then /^(?:they|I) (should|should not) see "([^"]*)"$/ do |shouldornot, content| page.send shouldornot, have_content(content) end

I guess I could get away with using placeholders and transforms, but I find regular expressions to be useful and not that hard to work with.

I'm also curious about the spork decision. I like using guard and spork to keep things going in the background and not break my flow.

I agree with the nested steps, though. Those get ugly quick. There should still be a nice way to package more granular (I click x, I fill in Y) steps for higher level reuse (I fill out the login form).

I'm having a hard enough time getting my company to use it, that I'll probably never get them close to sponsoring it, but I am excited about 2.0 and hope to be able to contribute some code.

By: Ankur

Ankur — Tue, 01 May 2012 19:57:19 +0000

You piqued my curiosity with the getting rid of regex. I don’t have much problem with regex because I am try not to write crazy steps. I say “create a user”, not “create a user with email: xx@xx.com and firstname: dd”. People try to stuff too much information into the steps I think. Interesting what the alternative is.

By: squarism

squarism — Tue, 01 May 2012 15:21:34 +0000

Why do you want to kill spork/drb support? Is spork falling out of favor in the community in lieu of something else?

By: Richard Lawrence

Richard Lawrence — Tue, 01 May 2012 14:23:29 +0000

I no longer use the wire protocol since retiring Cuke4Nuke, but I remember there being several wire protocol-based bridges to other languages. The wire protocol provides a quick way to spin up a new language implementation, so I'd hate to see it go away (unless no one is really using it). If getting Cucumber to a new language requires a full native port, that seems to me to put up an unnecessary barrier.

Scenario outlines can certainly be abused. But I've seen many cases where the data varied within the same structure across a set of scenarios. Refactoring to a scenario outline improved readability by putting the focus on the data. To compete with FitNesse, which handles this situation particularly well, I think scenario outlines need to stay.

By: Sam Livingston-Gray

Sam Livingston-Gray — Mon, 30 Apr 2012 21:14:23 +0000

As a programmer, I've definitely been responsible for some steaming piles of step definitions myself, and certainly didn't mean to imply otherwise. (=

I was more curious about non-developer participation in test automation. At my last job, I got our POs writing Cucumber and even managing their changes in Git -- but definitely wouldn't have expected them to actually implement.

I like the "Extract Step Definition" refactoring, and can see how it would work well with testers. Thanks!