Specs pass when run with other app specs, but fail when run independently

Testing RSpec
1

Hi there,

I’ve noticed something a little odd with the session_controller specs
that
are generated from the rails plugin restful_authentication. When
they’re
run with all the other app specs (i.e. when I first fire up autospec)
the
specs all pass. However, if I touch the session_controller_spec file so
only the session_controller specs are run, some fail with the error
message
protected method `logged_in?’ called for #SessionsController:0x19100e0

Can anyone explain why this might be or where I should start digging to
try
and resolve this?

Cheers,

Tim.

2

On Mon, Sep 1, 2008 at 6:22 PM, Tim H. [email protected] wrote:

and resolve this?
logged_in? is protected in the module AuthenticatedSystem. Chances are
that you’ve got a code example that’s doing this:

controller.logged_in?

instead of this:

controller.send(:logged_in?)

and something that’s not getting loaded when you run just
sessions_controller_spec is including AuthenticatedSystem into the
example group directly.

3

Hi David,

You were spot on. The generated authenticated_system_spec included
AuthenticatedSystem. If I include AuthenticatedSystem into the
SessionsController spec, then the specs all pass. This is a problem
with
the standard specs that resful_authentication builds for you - so I’ll
looking at getting those fixed…

I’m kind of curios that the specs are testing these protected methods -
I
would have expected that’s generally not a done thing as they’re not a
public part of the API?

I guess there’s 3 options as to how to patch:

  1. include AuthenticatedSystem, or
  2. change the specs to use .send, or
  3. remove the specs that are calling protected methods.

Do you have any guidance on the best path forward here?

Cheers,

Tim.

4

Tim H. wrote:

not a public part of the API?
Yep, you’re right. In general specing protected/private methods isn’t
something you want to do. The only time I have a spec for such a method
is a result of a refactoring. Since the goal is to spec the behaviour
of an object it makes sense IMO to use black box testing and only spec
the public API as you pointed out. Whenever I find myself wanting to
spec non-public methods or to stub them I take that as a hint to extract
the methods out into other objects and then spec their public
interfaces. restful_auth does several things from a testing and design
point of view that aren’t ideal though.

I guess there’s 3 options as to how to patch:

  1. include AuthenticatedSystem, or
  2. change the specs to use .send, or
  3. remove the specs that are calling protected methods.

If you really want to spec the protected methods or want to keep the
existing specs around I would favor using the send method because it
keeps you “feeling dirty” everytime you do it.

Removing the specs that are calling the protected methods would be
better IMO but you could not simply remove them… they would need to be
refactored to be specing the public API while still covering all of the
functionality provided in the protected methods. Again, the fact that
they have been specing the protected methods is an indication that
another object may want to be born to handle the extra responsibility…

Just my two cents… HTH,

Ben

5

functionality provided in the protected methods. Again, the fact that
they have been specing the protected methods is an indication that
another object may want to be born to handle the extra
responsibility…

+1. The desire to unit test private methods always rings the
‘refactor: extract class’ siren in my head.

6

Actually, it was patched in June. The patch author chose to use .send.

Cheers,

Tim.