Problems with plugins?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi there

I’ve run into a bit of a problem that I can’t seem to figure out. I
have a model class User which includes our acts_as_role_context
library. This lib acts like most other acts_as libs, evaluating
class and instance methods at runtime. When I try to stub methods
that are defined in acts_as_role_context, I get strange behavior.
Perhaps it’s just me. I am a bit under the weather, and the Nyquil
could be clouding my thinking. :slight_smile:

Here is my spec. It’s pretty simple, I just want to ensure that the
correct redirect happens when it should. For the record, the
controller works as expected outside of rspec.


require File.dirname(FILE) + ‘/…/spec_helper’

describe MemberNetworkController do
before(:each) do
controller.should_receive(:beta_lockdown).and_return true
login
end

after(:each) do
logout
end

describe “on GET to add_as_friend” do
it “should redirect to /network/friends” do
logged_in_user.stub!(:add_user_to_role)
controller.stub!(:make_friend_activity)
get :add_as_friend, :key => logged_in_user.key
response.should redirect_to("/members/#{logged_in_user.id}/
network/friends")
end
end
end


The line in question is logged_in_user.stub!(:add_user_to_role).
User#add_user_to_role is defined in acts_as_role_context.rb. I’ll
not paste the entire file unless requested. It’s fairly large. the
instance method #add_user_to_role looks like this.


     def add_user_to_role(user, role_or_key)
       role = self.class.sanitize_role( role_or_key )
       binding = role_bindings.find( :first, :conditions=>

[ ‘role_id=? AND user_id=?’, role.id, user.id ] )
if ( binding.nil? )
role_bindings.create
( :context=>self, :user=>user, :role=>role )
end
end


When #add_user_to_role is called in the controller during my spec,
the method is run, rather than being a stub as I would expect. Is
this expected and/or known behavior? Any comments and direction are
very much appreciated.

Thanks
Lance!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iD8DBQFHp2AG+EgDjU0WSaoRArYDAJ92Wpp1Nkybqk7lb8fY+of+tcIawACaAyRk
y6Lo0iCvWS8/afBDTx42XiY=
=dfEK
-----END PGP SIGNATURE-----

On Feb 4, 2008 12:57 PM, Lance B. [email protected]
wrote:

Perhaps it’s just me. I am a bit under the weather, and the Nyquil
before(:each) do
logged_in_user.stub!(:add_user_to_role)
User#add_user_to_role is defined in acts_as_role_context.rb. I’ll
( :context=>self, :user=>user, :role=>role )
end
end


When #add_user_to_role is called in the controller during my spec,
the method is run, rather than being a stub as I would expect. Is
this expected and/or known behavior? Any comments and direction are
very much appreciated.

My best guess is that the instance of logged_in_user is not the same
one that the controller action is using. You’re going through the
controller and passing it a key, at which point it’s probably using
that key to access the logged in user from a source that is not the
same as your logged_in_user method in the spec.

HTH,
David

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Feb 4, 2008, at 2:34 PM, David C. wrote:

controller and passing it a key, at which point it’s probably using
that key to access the logged in user from a source that is not the
same as your logged_in_user method in the spec.

Yes, that was my thought as well. So, I printed the ID of the logged
in user in the spec and the ID in the controller. The IDs were the
same. After that, I sent this note to the list.

But, it turns out I should have been more thorough in my
investigation. Instead of printing out the ID, this time I printed
the object itself and found:

#User:0x303fc5c
#User:0x2fa9bbc

So you are correct! Thanks. :slight_smile:

Lance

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iD8DBQFHp20H+EgDjU0WSaoRAnNkAJ9GpF2noGGfbfMyzXFJ3S8WxncnPACfdxHZ
ukGJeaOcZ8vnesebC7hRgD0=
=8cNF
-----END PGP SIGNATURE-----

On Feb 4, 2008 1:52 PM, Lance B. [email protected]
wrote:

the method is run, rather than being a stub as I would expect. Is
in user in the spec and the ID in the controller. The IDs were the
same. After that, I sent this note to the list.

But, it turns out I should have been more thorough in my
investigation. Instead of printing out the ID, this time I printed
the object itself and found:

#User:0x303fc5c
#User:0x2fa9bbc

So you are correct! Thanks. :slight_smile:

Sure. You good on how to solve it?