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
On 8 May 2009, at 05:55, Mike Doel wrote:> 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. > > MikeGreat stuff, Mike. I had a similar thought a while back, but it never really took off: http://www.mail-archive.com/rspec-users at rubyforge.org/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 Wynne http://beta.songkick.com http://blog.mattwynne.net
On 8 May 2009, at 09:12, aslak hellesoy wrote:> > > On 8 May 2009, at 05:55, Mike Doel wrote: > > 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 > > Great stuff, Mike. > > I had a similar thought a while back, but it never really took off: > http://www.mail-archive.com/rspec-users at rubyforge.org/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. > > 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 ;-) > > AslakSo 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
On 8 May 2009, at 15:24, aslak hellesoy wrote:>>> 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? >>> > 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?Yes, exactly. WDYT? Matt Wynne http://beta.songkick.com http://blog.mattwynne.net
On Fri, May 8, 2009 at 10:24 AM, aslak hellesoy <aslak.hellesoy at 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 at gmail.com) ? ESCAPE POD - The Science Fiction Podcast Magazine ? http://www.escapepod.org
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
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
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, > SteveI"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
On May 12, 2009, at 4:15 PM, Ben Mabey wrote:> 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....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