Re: [rspec-users] got/expects causes mental layering violation
David Chelimsky wrote:
> On 8/2/07, Jay Levitt <[EMAIL PROTECTED]> 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)
>> false
>>end
>> end
>>
>> .. C.new.should == other...
>>
>> expected other, got # (using ==)
>
> What did it really call other? The output should be evaluating a
> variable there, not naming it.
Right.. sorry, I over-simplified the example. It's more like:
# class
class C
def initialize(name, value)
@name = name
@value = value
end
def ==(other)
@value == other
end
end
# spec
..
c = C.new("name", 0)
c.should == 1
# output
expected 1, got # (using ==)
And that's confusing at first glance, because it implies that it was
trying to compare 1 to the whole object, when obviously the redefined ==
function would compare it to C.value (which == 0)!
In an ideal world, rspec would tell me "expected 1, got 0". But that,
of course, is impossible without reverse-engineering an == function to
see what it's really doing.
I'm not sure there is an actual solution, just throwing it out there to
see if my confusion was common...
Jay
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] got/expects causes mental layering violation
On 8/2/07, Jay Levitt <[EMAIL PROTECTED]> 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) > false >end > end > > .. C.new.should == other... > > expected other, got # (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: # > > 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 would expect. 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. Cheers, David > > Jay > > ___ > rspec-users mailing list > rspec-users@rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
[rspec-users] got/expects causes mental layering violation
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) false end end .. C.new.should == other... expected other, got # (using ==) 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: # but much prettier and better worded. Or do I just call this a learning experience? Jay ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
