[rspec-users] issues with the trunk of rspec-rails

[nathan@pivotalsf.com]

Snipping down to relevant questions:


On Feb 10, 8:49 pm, David Chelimsky <dchelim... at gmail.com> wrote:
> On Tue, Feb 10, 2009 at 2:02 PM, Nathan Wilmes <nat... at pivotallabs.com> wrote:
> > (2) The render override for RSpec controllers only takes one argument.  This
> > means that any controller using two argument forms will fail.
>
> > Our biggest use case for the two-argument controller form is this:  render
> > :update, :status => 404 do {}
> > This case is still allowable and not deprecated in Rails 2.2.2.
>
> I can reinstate the extra arg. Are you looking for it to be handled in
> some way? Or just to not blow up?

It shouldn't blow up - right now it gives argument errors.  It _ought_
to behave identically to
render :update => true, :status => 404 (Rails 2.2.2 converts the first
form to the second).

> > (3) with_tag is completely broken, as it tries to use the outer class as the
> > subject of 'with_tag', rather than the have_tag matcher that it lives
> > inside.
>
> Was it working before and the upgrade broke existing specs? Or is this
> a general observation?

Yes, the upgrade broke existing specs.. it used to work fine as of
rspec 1.1.4.
 The breakage appears to have something to do with the 'subject'
functionality.

>
> > (4) assigns(:xxx) will give really bad errors if your class doesn't happen
> > to define == in such a way that it can equate to FalseClass.
>
> Can you provide an example?

Let's say I have a simple object class Foo, defined as:

class Foo
  def initialize(bar)
    @bar = bar
  end
  attr_reader :bar

  def ==(other)
    self.bar == other.bar
  end
end

and a controller that sets a model variable @foo to Foo.new.

If you run an rspec controller spec and ask it about assigns(:foo), it
will complain with
an error about how it doesn't know what the 'bar' method is on
FalseClass.  It does this
the moment you ask for assigns(:foo).

Not the biggest deal once you understand what's going on (you can
solve it by making the == method smart
enough to return false unless other is a Foo class) but a very
confusing error to track down.

=N