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.
4c63a3e984016307fc7dc418a9fd75f1?d=identicon&s=25 Mike Doel (Guest)
on 2009-05-08 06: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
Cdf378de2284d8acf137122e541caa28?d=identicon&s=25 Matt Wynne (mattwynne)
on 2009-05-08 09:07
(Received via mailing list)
On 8 May 2009, at 05:55, Mike Doel 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/rspec-users@rubyforge....

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 Wynne
http://beta.songkick.com
http://blog.mattwynne.net
0be0e4aa42aacd9a8a95c792de273ca7?d=identicon&s=25 Aslak Hellesøy (aslakhellesoy)
on 2009-05-08 10: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
4c63a3e984016307fc7dc418a9fd75f1?d=identicon&s=25 Mike Doel (Guest)
on 2009-05-08 14: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 Doel
mike@mikedoel.com


On May 8, 2009, at 1:12 AM, aslak hellesoy <aslak.hellesoy@gmail.com>
Cdf378de2284d8acf137122e541caa28?d=identicon&s=25 Matt Wynne (mattwynne)
on 2009-05-08 15: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 Wynne
http://blog.mattwynne.net
http://www.songkick.com
0be0e4aa42aacd9a8a95c792de273ca7?d=identicon&s=25 Aslak Hellesøy (aslakhellesoy)
on 2009-05-08 16: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?
Cdf378de2284d8acf137122e541caa28?d=identicon&s=25 Matt Wynne (mattwynne)
on 2009-05-09 12: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 Wynne
http://beta.songkick.com
http://blog.mattwynne.net
994e42bda994be2cd1d791f18ee6d561?d=identicon&s=25 Stephen Eley (Guest)
on 2009-05-09 16:12
(Received via mailing list)
On Fri, May 8, 2009 at 10:24 AM, aslak hellesoy
<aslak.hellesoy@gmail.com> wrote:
>> [ Matt Wynne: ]
>> 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 Eley (sfeley@gmail.com)
  ESCAPE POD - The Science Fiction Podcast Magazine
  http://www.escapepod.org
0be0e4aa42aacd9a8a95c792de273ca7?d=identicon&s=25 Aslak Hellesøy (aslakhellesoy)
on 2009-05-09 16:47
(Received via mailing list)
> On Fri, May 8, 2009 at 10:24 AM, aslak hellesoy
> <aslak.hellesoy@gmail.com> wrote:
> >> [ Matt Wynne: ]
> >> 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
Ee6788c2faaad7a5cd0bc466c9ea60d8?d=identicon&s=25 aidy lewis (Guest)
on 2009-05-11 11: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
0be0e4aa42aacd9a8a95c792de273ca7?d=identicon&s=25 Aslak Hellesøy (aslakhellesoy)
on 2009-05-11 12: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
Cfa71089e69037dd7e7eab858e7c4f69?d=identicon&s=25 Steven Rogers (Guest)
on 2009-05-12 22: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
C694a032be7518a0d704318895f8fe1d?d=identicon&s=25 Ben Mabey (mabes)
on 2009-05-12 23:16
(Received via mailing list)
Steven Rogers 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
Cfa71089e69037dd7e7eab858e7c4f69?d=identicon&s=25 Steven Rogers (Guest)
on 2009-05-13 01:13
(Received via mailing list)
On May 12, 2009, at 4:15 PM, Ben Mabey 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.