[rspec-users] using RSpec's trunk in non-rails projects w/ Autotest
I believe for rails projects you can put rspec's code repos into vendor/plugins, and autotest will automatically use the rspec binary in that directory, and not the gem installed. Is there an easy way to do this for non-rails projects? There are a few advancements on trunk which I would like to take advantage of. Tips welcome ; ). Scott Taylor ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Stubbing Enumerable#each
On 8/5/07, Scott Taylor <[EMAIL PROTECTED]> wrote:
>
> I have a mock of an instance of a class which descends from Array:
>
> class ArrayDescendent < Array; end
>
> #... in the specs...
> @descendent = mock ArrayDescendent
>
> How would I stub out ArrayDescendent#each, which is inherited from
> Array, to return multiple values successively? I could use
> and_yield, but that is raising an arity error (the anonymous function/
> block should expect only *one value at a time, but and_yield is
> yielding both values once). Should I be using a lambda expression here?
>
> Tips are welcome...Thanks,
>
> Scott
> ___
> rspec-users mailing list
> rspec-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
Hey Scott,
I'm not sure if there's a way you can currently do that (there may be
and I just couldn't figure it out). However I agree it's useful, and
I whipped up a quick patch to provide that behavior.
http://rubyforge.org/tracker/index.php?func=detail&aid=12841&group_id=797&atid=3151
My example spec is
it "should support yielding consecutive values" do
yielded_values = []
@obj.stub!(:method_that_yields).and_yield_consecutively("abc",
123, :foobar)
@obj.method_that_yields {|val| yielded_values << val }
yielded_values.should == [ "abc", 123, :foobar ]
@obj.rspec_verify
end
How's that?
Pat
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
[rspec-users] pending w/ no string
Is there some reason that pending() *MUST* take an argument? Scott ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
[rspec-users] Stubbing Enumerable#each
I have a mock of an instance of a class which descends from Array: class ArrayDescendent < Array; end #... in the specs... @descendent = mock ArrayDescendent How would I stub out ArrayDescendent#each, which is inherited from Array, to return multiple values successively? I could use and_yield, but that is raising an arity error (the anonymous function/ block should expect only *one value at a time, but and_yield is yielding both values once). Should I be using a lambda expression here? Tips are welcome...Thanks, Scott ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] reusable specs - almost there
On 8/5/07, David Green <[EMAIL PROTECTED]> wrote:
>
> that's a great point, but there are some things about shared behaviours I
> don't like. for example, I have 14 different contexts I'm testing (and more
> to come) in 8 controllers.
>
> I can do this:
>
> describe MyController do
> it_should_behave_like "context 1"
> it_should_behave_like "context 2"
> .
> .
> it_should_behave_like "context 14"
> end
>
> but then I lose the context info in the output, it just displays one long
> list of examples.
Interesting. This is kind of backwards from how I envision shared
behaviours. To me, a shared behaviour is a behaviour that is shared
across objects, not contexts. In other words:
describe "any controller", :shared => true do
it "should do a when b" { ... }
end
describe "a specific controller" do
it_should_behave_like "any controller"
end
As opposed to:
describe "any controller when the user is logged in", :shared => true do
it "should do a when b" { ... }
end
describe "a specific controller" do
it_should_behave_like "any controller when the user is logged in"
end
Subtle difference, but I'm sure it guides in a different direction.
The problem you're experiencing is not new, and I'm definitely
interested in discussing solutions for it, but I'm much more
interested in ways rspec could improve than ways to work around
rspec's deficiencies.
> The alternative is:
>
> describe MyController, "context 1" do
> it_should_behave_like "context 1"
> end
> describe MyController, "context 2" do
> it_should_behave_like "context 2"
> end
> .
> .
> describe MyController, "context 14" do
> it_should_behave_like "context 14"
> end
>
> this way the context info is preserved in the output, but it's more work,
> especially across 8 controllers.
>
> another thing is, depending on the model being used, controllers will
> instantiate variables of different names. e.g. in the "dvd" controller, an
> instance of the Dvd model would be stored in @dvd, whereas in the "book"
> controller, it would be in @book . using dynamic specs, I can make my
> examples more specific depending on the controller being tested e.g. :
>
> # obj and var passed in as parameters
> it "should load a #{obj.class} object into @#{varname}" do
> get :show
> assigns[var_name].should == obj
> end
>
> I could put obj and varname into instance variables in the before() method,
> but they're only available in the example block, not from the example title
>
> these are minor complaints really, but as my project grows, they become more
> of an issue.
Understood - although, if all of these controllers are behaving
exactly the same way with only a variable name or two difference, it
seems to me that the duplication problem is in the code, not the
specs. Perhaps there is some common code that could be extracted to a
module - then you can have specs for that module and specify that the
module should be included in each of your controllers.
WDYT?
>
>
>
> David Chelimsky-2 wrote:
> >
> > On 8/4/07, David Green <[EMAIL PROTECTED]> wrote:
> >>
> >> I have a lot of controllers with virtually identical functionality for
> >> most
> >> actions. I've been using shared behaviours to DRY things up a bit, but I
> >> still have to create separate behaviours for each context before I can
> >> use
> >> the shared behaviours
> >>
> >> what I have now is a generic file which contains all the behaviours and
> >> examples common to all the controllers, and that file gets loaded from an
> >> actual controller spec. The generic file knows which controller to test
> >> by
> >> calling kontroller(), which is defined in the controller spec.
> >>
> >> here's a very simplified example:
> >> http://pastebin.com/m6b47bae9
> >>
> >> It works great when I run the specs individually, but when I use rake,
> >> specs
> >> begin to fail and i think it's because the value of kontroller() is set
> >> to
> >> whatever it returns the first time it gets called. Here's the rake output
> >> from running the specs shown above:
> >>
> >>
> >> FooController
> >> .FooController
> >> .
> >>
> >> Finished in 0.041793 seconds
> >> 2 examples, 0 failures
> >>
> >> I would expect it to print FooController and then BarController ...
> >> interestingly, if I insert 'puts kontroller.to_s' *outside* of the
> >> describe
> >> block, then it does output the names of both controllers as expected.
> >>
> >> does anyone know of a solution?
> >> thanks
> >>
> >> dave
> >
> > I'm all for keeping things DRY, but NEVER at the risk of clarity.
> > You've got to balance DRY and readability/clarity. Anybody familiar
> > with rspec can look at this:
> >
> > =
> > describe FooController do
> > it_should_behave_like "All Controllers"
> > end
> > =
> >
> > and understand what that means: A FooController should behave like All
> > Controllers. Perhaps there is a split second of mental mapping: "Oh,
> > there must be some behaviour described for all controllers
Re: [rspec-users] reusable specs - almost there
I agree with David, I think this is too much magic.
You'll often have more duplication in specs than you will in
production code. That's not a bad thing though, because specs need to
be explicit about the behavior being performed. Duplication doesn't
lead to the same mistakes that it does in production code.
You can and should factor out stuff when doing so won't hurt the
clarity of the specs. However when you have to think hard to figure
out what's going on, you lose one of the main benefits of RSpec. It's
all about making your spec code easy to parse.
Solving the problem of 14 different shared contexts isn't really hard.
%w(admin_context regular_user_context manager_context).each do |con|
describe MyController do
it_should_be_have_like con
end
end
Pat
On 8/5/07, David Green <[EMAIL PROTECTED]> wrote:
>
> that's a great point, but there are some things about shared behaviours I
> don't like. for example, I have 14 different contexts I'm testing (and more
> to come) in 8 controllers.
>
> I can do this:
>
> describe MyController do
> it_should_behave_like "context 1"
> it_should_behave_like "context 2"
> .
> .
> it_should_behave_like "context 14"
> end
>
> but then I lose the context info in the output, it just displays one long
> list of examples.
> The alternative is:
>
> describe MyController, "context 1" do
> it_should_behave_like "context 1"
> end
> describe MyController, "context 2" do
> it_should_behave_like "context 2"
> end
> .
> .
> describe MyController, "context 14" do
> it_should_behave_like "context 14"
> end
>
> this way the context info is preserved in the output, but it's more work,
> especially across 8 controllers.
>
> another thing is, depending on the model being used, controllers will
> instantiate variables of different names. e.g. in the "dvd" controller, an
> instance of the Dvd model would be stored in @dvd, whereas in the "book"
> controller, it would be in @book . using dynamic specs, I can make my
> examples more specific depending on the controller being tested e.g. :
>
> # obj and var passed in as parameters
> it "should load a #{obj.class} object into @#{varname}" do
> get :show
> assigns[var_name].should == obj
> end
>
> I could put obj and varname into instance variables in the before() method,
> but they're only available in the example block, not from the example title
>
> these are minor complaints really, but as my project grows, they become more
> of an issue.
>
>
>
> David Chelimsky-2 wrote:
> >
> > On 8/4/07, David Green <[EMAIL PROTECTED]> wrote:
> >>
> >> I have a lot of controllers with virtually identical functionality for
> >> most
> >> actions. I've been using shared behaviours to DRY things up a bit, but I
> >> still have to create separate behaviours for each context before I can
> >> use
> >> the shared behaviours
> >>
> >> what I have now is a generic file which contains all the behaviours and
> >> examples common to all the controllers, and that file gets loaded from an
> >> actual controller spec. The generic file knows which controller to test
> >> by
> >> calling kontroller(), which is defined in the controller spec.
> >>
> >> here's a very simplified example:
> >> http://pastebin.com/m6b47bae9
> >>
> >> It works great when I run the specs individually, but when I use rake,
> >> specs
> >> begin to fail and i think it's because the value of kontroller() is set
> >> to
> >> whatever it returns the first time it gets called. Here's the rake output
> >> from running the specs shown above:
> >>
> >>
> >> FooController
> >> .FooController
> >> .
> >>
> >> Finished in 0.041793 seconds
> >> 2 examples, 0 failures
> >>
> >> I would expect it to print FooController and then BarController ...
> >> interestingly, if I insert 'puts kontroller.to_s' *outside* of the
> >> describe
> >> block, then it does output the names of both controllers as expected.
> >>
> >> does anyone know of a solution?
> >> thanks
> >>
> >> dave
> >
> > I'm all for keeping things DRY, but NEVER at the risk of clarity.
> > You've got to balance DRY and readability/clarity. Anybody familiar
> > with rspec can look at this:
> >
> > =
> > describe FooController do
> > it_should_behave_like "All Controllers"
> > end
> > =
> >
> > and understand what that means: A FooController should behave like All
> > Controllers. Perhaps there is a split second of mental mapping: "Oh,
> > there must be some behaviour described for all controllers that the
> > FooController should adopt."
> >
> > Compare that to your example:
> >
> > =
> > def kontroller
> > FooController
> > end
> >
> > load File.dirname(__FILE__) + '/all_controllers.rb'
> > =
> >
> > First of all - how is that any more DRY than the example above?
> > Perhaps you save a few keystrokes, but if you think that makes it more
> > DRY then you don't really understand what DRY is all about.
> >
> > Second of all,
Re: [rspec-users] reusable specs - almost there
that's a great point, but there are some things about shared behaviours I
don't like. for example, I have 14 different contexts I'm testing (and more
to come) in 8 controllers.
I can do this:
describe MyController do
it_should_behave_like "context 1"
it_should_behave_like "context 2"
.
.
it_should_behave_like "context 14"
end
but then I lose the context info in the output, it just displays one long
list of examples.
The alternative is:
describe MyController, "context 1" do
it_should_behave_like "context 1"
end
describe MyController, "context 2" do
it_should_behave_like "context 2"
end
.
.
describe MyController, "context 14" do
it_should_behave_like "context 14"
end
this way the context info is preserved in the output, but it's more work,
especially across 8 controllers.
another thing is, depending on the model being used, controllers will
instantiate variables of different names. e.g. in the "dvd" controller, an
instance of the Dvd model would be stored in @dvd, whereas in the "book"
controller, it would be in @book . using dynamic specs, I can make my
examples more specific depending on the controller being tested e.g. :
# obj and var passed in as parameters
it "should load a #{obj.class} object into @#{varname}" do
get :show
assigns[var_name].should == obj
end
I could put obj and varname into instance variables in the before() method,
but they're only available in the example block, not from the example title
these are minor complaints really, but as my project grows, they become more
of an issue.
David Chelimsky-2 wrote:
>
> On 8/4/07, David Green <[EMAIL PROTECTED]> wrote:
>>
>> I have a lot of controllers with virtually identical functionality for
>> most
>> actions. I've been using shared behaviours to DRY things up a bit, but I
>> still have to create separate behaviours for each context before I can
>> use
>> the shared behaviours
>>
>> what I have now is a generic file which contains all the behaviours and
>> examples common to all the controllers, and that file gets loaded from an
>> actual controller spec. The generic file knows which controller to test
>> by
>> calling kontroller(), which is defined in the controller spec.
>>
>> here's a very simplified example:
>> http://pastebin.com/m6b47bae9
>>
>> It works great when I run the specs individually, but when I use rake,
>> specs
>> begin to fail and i think it's because the value of kontroller() is set
>> to
>> whatever it returns the first time it gets called. Here's the rake output
>> from running the specs shown above:
>>
>>
>> FooController
>> .FooController
>> .
>>
>> Finished in 0.041793 seconds
>> 2 examples, 0 failures
>>
>> I would expect it to print FooController and then BarController ...
>> interestingly, if I insert 'puts kontroller.to_s' *outside* of the
>> describe
>> block, then it does output the names of both controllers as expected.
>>
>> does anyone know of a solution?
>> thanks
>>
>> dave
>
> I'm all for keeping things DRY, but NEVER at the risk of clarity.
> You've got to balance DRY and readability/clarity. Anybody familiar
> with rspec can look at this:
>
> =
> describe FooController do
> it_should_behave_like "All Controllers"
> end
> =
>
> and understand what that means: A FooController should behave like All
> Controllers. Perhaps there is a split second of mental mapping: "Oh,
> there must be some behaviour described for all controllers that the
> FooController should adopt."
>
> Compare that to your example:
>
> =
> def kontroller
> FooController
> end
>
> load File.dirname(__FILE__) + '/all_controllers.rb'
> =
>
> First of all - how is that any more DRY than the example above?
> Perhaps you save a few keystrokes, but if you think that makes it more
> DRY then you don't really understand what DRY is all about.
>
> Second of all, what does it actually mean? Where's the story? How is a
> non-developer going to look at that and have any context for what that
> means? I'm a developer and I don't know what it means. Sure I can
> figure it out, but, in my opinion, it's just nowhere near as clear as
> the example above.
>
> FWIW,
> David
> ___
> rspec-users mailing list
> rspec-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
>
--
View this message in context:
http://www.nabble.com/reusable-specs---almost-there-tf4216708.html#a12007548
Sent from the rspec-users mailing list archive at Nabble.com.
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] reusable specs - almost there
On 8/4/07, David Green <[EMAIL PROTECTED]> wrote: > > I have a lot of controllers with virtually identical functionality for most > actions. I've been using shared behaviours to DRY things up a bit, but I > still have to create separate behaviours for each context before I can use > the shared behaviours > > what I have now is a generic file which contains all the behaviours and > examples common to all the controllers, and that file gets loaded from an > actual controller spec. The generic file knows which controller to test by > calling kontroller(), which is defined in the controller spec. > > here's a very simplified example: > http://pastebin.com/m6b47bae9 > > It works great when I run the specs individually, but when I use rake, specs > begin to fail and i think it's because the value of kontroller() is set to > whatever it returns the first time it gets called. Here's the rake output > from running the specs shown above: > > > FooController > .FooController > . > > Finished in 0.041793 seconds > 2 examples, 0 failures > > I would expect it to print FooController and then BarController ... > interestingly, if I insert 'puts kontroller.to_s' *outside* of the describe > block, then it does output the names of both controllers as expected. > > does anyone know of a solution? > thanks > > dave I'm all for keeping things DRY, but NEVER at the risk of clarity. You've got to balance DRY and readability/clarity. Anybody familiar with rspec can look at this: = describe FooController do it_should_behave_like "All Controllers" end = and understand what that means: A FooController should behave like All Controllers. Perhaps there is a split second of mental mapping: "Oh, there must be some behaviour described for all controllers that the FooController should adopt." Compare that to your example: = def kontroller FooController end load File.dirname(__FILE__) + '/all_controllers.rb' = First of all - how is that any more DRY than the example above? Perhaps you save a few keystrokes, but if you think that makes it more DRY then you don't really understand what DRY is all about. Second of all, what does it actually mean? Where's the story? How is a non-developer going to look at that and have any context for what that means? I'm a developer and I don't know what it means. Sure I can figure it out, but, in my opinion, it's just nowhere near as clear as the example above. FWIW, David ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
