On Apr 4, 2010, at 11:21 PM, Marcelo de Moraes Serpa wrote:
> For example, I have this scenario where a Directory model will only save if
it can connect to the LDAP server. In a test I''m writting, though,
connecting to the LDAP server is not relevant, so I tried doing this:
>
> context "LDAP is on" do
> before(:each) do
> Directory.stub!(:authenticate_user).and_return(@user).
> @account.directory = Directory.make :ldap_on
> end
> ...
> end
>
> However, the Directory.make fails (since the before_save ldap test fails,
because authenticate_user can''t connect to the LDAP server). The issue
is that it stubs the method as a singleton method of Directory.
That is how stubbing works in RSpec, and every other Ruby stubbing/mocking
framework I know of. If you tell a class to stub a method, it stubs a class
method. If you want to stub an instance method, you stub it directly on an
instance. Mocha has an any_instance method, which RSpec doesn''t have
(yet), that allows you to say:
Directory.any_instance.stubs(:authenticate_user).returns(@user)
You can either switch to mocha and do that, or stub whatever creation mechanism
is being used:
directory = Directory.new
directory.stub(:authenticate_user).and_return(@user)
Directory.stub(:new).and_return(directory)
account.directory = Directory.make :ldap_on
> One alternative is opening the Directory class and redefining the
authenticate_user method, but I''d like to know if rSpec supports
somehow stubing a class and let it stub instance too.
I don''t think you''d want to stub the same method on the class
and instance automatically. You might end up with false positives when one
object calls a class method on an instance.
HTH,
David