Forum: RSpec Sharing common Cuke steps

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Mike D. (Guest)
on 2009-05-08 08:57
(Received via mailing list)
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:

http://github.com/mdoel/cukesteps/tree/master

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
Matt W. (Guest)
on 2009-05-08 11:07
(Received via mailing list)
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@...

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
Aslak H. (Guest)
on 2009-05-08 12:14
(Received via mailing list)
>> 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
;-)

Aslak
Mike D. (Guest)
on 2009-05-08 16:27
(Received via mailing list)
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>
Matt W. (Guest)
on 2009-05-08 17:14
(Received via mailing list)
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 ;-)
>
> 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
Aslak H. (Guest)
on 2009-05-08 18:30
(Received via mailing list)
>> 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?
Matt W. (Guest)
on 2009-05-09 14:40
(Received via mailing list)
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
Stephen E. (Guest)
on 2009-05-09 18:12
(Received via mailing list)
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
Aslak H. (Guest)
on 2009-05-09 18:47
(Received via mailing list)
> 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
aidy lewis (Guest)
on 2009-05-11 13:28
(Received via mailing list)
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
Aslak H. (Guest)
on 2009-05-11 14:26
(Received via mailing list)
>
> 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
Steven R. (Guest)
on 2009-05-13 00:58
(Received via mailing list)
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
Ben M. (Guest)
on 2009-05-13 01:16
(Received via mailing list)
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
Steven R. (Guest)
on 2009-05-13 03:13
(Received via mailing list)
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
This topic is locked and can not be replied to.