Sharing common Cuke steps


#1

Cucumber is awesome and destined to rule the world. As that starts to
happen, has there been any thought of a mechanism for the community to
build a library of common, generally useful steps that can be used
across projects? I’ve got stuff that I use for myself at:

This is stuff that I wish were in the default webrat_steps.rb file
that you get at the start. Would it be better to fork Cucumber and
add them there and send a pull request to Aslak?

It seems to me that there’s an opportunity for packaging together and
sharing steps, but am curious of folks thoughts on the best way to go
about this.

Mike


#2

On 8 May 2009, at 05:55, Mike D. wrote:

It seems to me that there’s an opportunity for packaging together
and sharing steps, but am curious of folks thoughts on the best way
to go about this.

Mike

Great stuff, Mike.

I had a similar thought a while back, but it never really took off:
http://www.mail-archive.com/removed_email_address@domain.invalid/msg07936.html

I feel like this might be better suited to being a separate project,
as you’ll eventually have steps that are only relevant in certain
contexts (we have quite a few that depend on factory_girl, for
example), and it’s likely to change at a different rate to the core
cucumber code.

It’s almost like you want a kind of plug-in mechanism for sharing re-
usable step libraries.

Matt W.
http://beta.songkick.com
http://blog.mattwynne.net


#3

This is stuff that I wish were in the default webrat_steps.rb file that
Great stuff, Mike.
step libraries.

I agree with Matt - this sounds great. Could you add a link to the
related
tools page in the wiki?

I think we already have a plugin mechanism for this. It’s called
RubyGems
:wink:

Aslak


#4

Ok. That sounds like a good plan. I’ll update it to a gem and submit
the wiki change when I get home from vegas.

Mike D.
removed_email_address@domain.invalid

On May 8, 2009, at 1:12 AM, aslak hellesoy removed_email_address@domain.invalid


#5

projects? I’ve got stuff that I use for myself at:

to change at a different rate to the core cucumber code.
Aslak
require ‘cucumber/steps/factory_girl’

or in another project that uses the command line:

   gem 'cucumber-steps'

   require 'cucumber/steps/console'

Is that the kind of thing you mean?

Yes.

I think it would be good to allow for steps that cater to different use
cases to all be in the same library but allow you to pick and chose the ones
that are relevant to your project.

So several files in the same gem? Different requires?


#6

On 8 May 2009, at 09:12, aslak hellesoy wrote:

Great stuff, Mike.
It’s almost like you want a kind of plug-in mechanism for sharing re-
usable step libraries.

I agree with Matt - this sounds great. Could you add a link to the
related tools page in the wiki?

I think we already have a plugin mechanism for this. It’s called
RubyGems :wink:

Aslak

So are you saying we’d put the steps in a gem, then include them using
require?

So I can do this in my env file:

gem ‘cucumber-steps’

require ‘cucumber/steps/webrat’
require ‘cucumber/steps/factory_girl’

or in another project that uses the command line:

gem ‘cucumber-steps’

require ‘cucumber/steps/console’

Is that the kind of thing you mean? I think it would be good to allow
for steps that cater to different use cases to all be in the same
library but allow you to pick and chose the ones that are relevant to
your project.

Matt W.
http://blog.mattwynne.net
http://www.songkick.com


#7

On Fri, May 8, 2009 at 10:24 AM, aslak hellesoy
removed_email_address@domain.invalid wrote:

[ Matt W.: ]
So are you saying we’d put the steps in a gem, then include them using require?

Yes.

Is there any reason not to accept them for inclusion in the Cucumber
gem? You already have precedent with the Webrat steps. Obviously
you’d need some set of standards of generality and quality, but you
could delegate someone else to handle the submissions process.
Candidates could be put up on a page in the Wiki, discussed, and then
taken off again when they’re rolled into a production release or
rejected.

I love the idea of a repository, but I don’t like the idea of having
still more highly coupled gems to manage. And I don’t think this
warrants it. I’d rather either see them in Cucumber, or a pure Web
resource where I can do my own copying-and-pasting.


Have Fun,
Steve E. (removed_email_address@domain.invalid)
ESCAPE POD - The Science Fiction Podcast Magazine
http://www.escapepod.org


#8

On 8 May 2009, at 15:24, aslak hellesoy wrote:

or in another project that uses the command line:
different use cases to all be in the same library but allow you to
pick and chose the ones that are relevant to your project.

So several files in the same gem? Different requires?

Yes, exactly. WDYT?

Matt W.
http://beta.songkick.com
http://blog.mattwynne.net


#9

On Fri, May 8, 2009 at 10:24 AM, aslak hellesoy
removed_email_address@domain.invalid wrote:

[ Matt W.: ]
So are you saying we’d put the steps in a gem, then include them using
require?

Yes.

Is there any reason not to accept them for inclusion in the Cucumber
gem?

Yes. It becomes too big for me to maintain and review patches.

You already have precedent with the Webrat steps. Obviously
you’d need some set of standards of generality and quality, but you
could delegate someone else to handle the submissions process.

I’ll consider this if the project shows that patches from others are
merged
in regularly, so that it doesn’t mean more maintenance for me.

Candidates could be put up on a page in the Wiki, discussed, and then
taken off again when they’re rolled into a production release or
rejected.

I love the idea of a repository, but I don’t like the idea of having
still more highly coupled gems to manage. And I don’t think this
warrants it. I’d rather either see them in Cucumber, or a pure Web
resource where I can do my own copying-and-pasting.

The project has to prove that it’s ready for it before it’s included.

Aslak


#10

Hi All

It seems to me that there’s an opportunity for packaging together and
sharing steps, but am curious of folks thoughts on the best way to go about
this.

Mike

Customer/Users are likely to have their ‘own’ language’ and that
providing library steps - could thus be argued - to negate BDD.

Also we are all using different ‘browser’ drivers.


Aidy
blog: www.agiletester.co.uk
twitter: http://twitter.com/aidy_lewis


#11

I want to stub a global method in a model spec, but I can’t figure out
what’s the equivalent in model specs for controller.stub! in
controller specs and template.stub! in view specs . . . at least, it
seems like I need to do that in order to make acts_as_audited happy in
models. Any thoughts?

Thanks,
Steve


#12

Steven R. wrote:

I want to stub a global method in a model spec, but I can’t figure out
what’s the equivalent in model specs for controller.stub! in
controller specs and template.stub! in view specs . . . at least, it
seems like I need to do that in order to make acts_as_audited happy in
models. Any thoughts?

Thanks,
Steve

I"m not sure what you mean by global method. Do you mean class method?
If so then ModelName.stub!(:class_method) should work. If you are
talking about an instance method then you just need to call stub! on the
instance (it can be a mock object or a real object.)

What is the exact problem you are running into though? Mocking may not
be the best option…

-Ben


#13

Customer/Users are likely to have their ‘own’ language’ and that
providing library steps - could thus be argued - to negate BDD.

That’s a good point Aidy. This is another reason why I’m reluctant to
put
them inside Cucumber proper.

Aslak


#14

On May 12, 2009, at 4:15 PM, Ben M. wrote:

I"m not sure what you mean by global method. Do you mean class
method? If so then ModelName.stub!(:class_method) should work. If
you are talking about an instance method then you just need to call
stub! on the instance (it can be a mock object or a real object.)

What is the exact problem you are running into though? Mocking may
not be the best option…

acts_as_audited has the line (acts_as_audited/lib/acts_as_audited/
audit_sweeper.rb:73)

 controller.send :current_user if controller.respond_to?

(:current_user)

which blows up in my audited models. I assume there’s something akin
to “controller” in controller specs and “template” in view specs that
makes it easy to do things like: controller.stub!
(:logged_in?).and_return(true) (vs. a stub on the model itself)

SR