[rspec-devel] Failure message for "string".should_equal "string"

[Wilson Bilkovich]

On 12/12/06, Antti Tarvainen <antti.tarvainen at iki.fi> wrote:
> On 12/11/06, Matthew Elder <mae at mindflowsolutions.com> wrote:
> > I think this might cause problems because from time to time people
> > will override the meaning of equal or eql.
>
> That would definitely be a good reason not to do it. Can you specify
> what kind of problems it might cause? The code I proposed would call
> the overriden equal? method just like should_equal does nowadays.
>
> Here's the code:
> > > class Should < Base
> > >   def equal(expected)
> > >     unless @target.equal?(expected)
> > >       if @target.inspect == expected.inspect
> > >         # Show message with object ids
> > >       else
> > >         # Show ordinary message
> > >       end
> > >     end
> > >   end
> > > end
>
> > If your using equals then you should _know_ what that means.
>
> Yes, but how many Test::Unit emigrants really do know what
> should_equal means? Most people don't read every word of the
> documentation.
>
> I am just afraid that problems with should_equal will annoy a lot of newcomers.
>

It does, yes. I've also had problems with the fact that the RSpec on
Rails plugin doesn't use HashWithIndifferentAccess.
When you mock out the controller params, for example, you have to use
strings, or else your expectations will fail.
While I agree with this philosophically, Rails people really seem to
complain about it.

I guess I'm voting for some slightly looser semantics, along with some
docs about how they've been loosened.