[rspec-users] got/expects causes mental layering violation
dchelimsky at gmail.com
Thu Aug 2 11:01:27 EDT 2007
On 8/2/07, Jay Levitt <lists-rspec at shopwatch.org> wrote:
> I was, for the first time, spec'ing a class that redefined ==. And my
> spec was incorrect, so == was returning false.
> The result was something like:
> class C
> def ==(other)
> .. C.new.should == other...
> expected other, got #<C:0x7f03c454> (using ==)
What did it really call other? The output should be evaluating a
variable there, not naming it.
> But wait! Why on earth is == returning the class itself instead of
> true/false? That shouldn't be possible. No, no time for coffee, let me
> go debug this for a few hours... oh. of course. == IS returning a
> boolean value, in this case, false; rspec is helpfully showing me
> C.inspect so I can see why they MIGHT differ, assuming I haven't
> redefined ==. Which I have.
> Would it be good, when == is redefined (or eql? or equals?) for the
> rspec output to indicate somehow what it's doing and why you might be
> seeing what you're seeing? Maybe something like
> expected C==other, but C!=other. You have redefined ==. C.inspect
> shows: #<C:...>
> but much prettier and better worded.
> Or do I just call this a learning experience?
I must be missing something. I don't really understand the problem you
are experiencing. Any class can redefine == at any time. Many library
classes do. That's just part of the language. You defined == to always
return false, so the feedback you got seems to be the feedback you
Even if you do explain this differently and I end up seeing it
differently, I don't think it's feasible for rspec to be trying to
discover what methods get defined, overridden, etc, and when.
> rspec-users mailing list
> rspec-users at rubyforge.org
More information about the rspec-users