[rspec-users] Unexpected message on :attr_accessor

David Chelimsky dchelimsky at gmail.com
Tue Dec 4 16:18:23 EST 2007


On Dec 4, 2007 3:00 PM, David Chelimsky <dchelimsky at gmail.com> wrote:
> On Dec 4, 2007 2:54 PM, Jonathan Linowes <jonathan at parkerhill.com> wrote:
> >
> > >>
> > >> This should be:
> > >>
> > >> @user.should_receive(:password_confirmation=)
> > >>
> > >
> > > Lots of beginners make this mistake. Maybe RSpec's mock framework
> > > should be smart enough to suggest this fix by itself.
> > >
> > > Patch anyone?
> > >
> > > Aslak
> > >>
> >
> > perhaps be even more explicit that it's an accessor, like
> >
> > User.should_set(:password_confirmation)
> > User.should_get(:password_confirmation)
>
> This is silly. Mock frameworks are not there to help you learn the
> language.

That was a knee-jerk reaction. Let me explain.

We already have should_receive(:message). :password_confirmation and
password_confirmation= are two completely different messages. So
saying should_set(:password_confirmation) hides what the message is
that you're looking for. RSpec does aim to make things readable and
consequently pleasing, but it's not here to protect you from having to
learn the language.

This is the same issue we had in rspec core w/ should equal(value).
There are 4 versions of equal in Ruby and they all have different
meanings, so we set up rspec to expose them, which means you have to
understand Ruby to understand what "should equal" means.

> Adding getter/setter knowledge into a framework is
> completely backwards.

Just following up on that thought - even though duplication is the
root of all evil in OO, so are getters and setters. They act like they
are encapsulating something, but really they encourage objects to
interact with the state of other objects instead of interacting with
the objects themselves and letting them manage their own state -
THATS's what encapsulation means - not hiding data behind a
getter/setter method. So having a first class construct in a mock
framework that encourages thinking in terms of getters and setters
seems like a step in the wrong direction.

FWIW,
David

>
> -1000
>
>
> >
> >
> > _______________________________________________
> > rspec-users mailing list
> > rspec-users at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-users
> >
>


More information about the rspec-users mailing list