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.
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.
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 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?
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.
On Fri, May 8, 2009 at 10:24 AM, aslak hellesoy [email protected] 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.
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?
On Fri, May 8, 2009 at 10:24 AM, aslak hellesoy [email protected] 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.
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.
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?
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…
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 forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
