Interdependency between RSpec files

I run my suite of tests, one test fails.
I run that one test file, no tests fail.

Something is carrying over between files and I can’t figure out what.
I tracked down the problem to the very line it’s occurring on, with
printouts before and after every call to make sure I know exactly what
is being reached.

In this spec I have 0 fixtures/mocks/stubs. The objects in this file
do not live anywhere outside of the file. This is a model spec and
I’m using all real objects to test it. In the “before” block I set up
some models, and in my spec itself I, in each test, make a couple
changes then call a model’s save method. That model has an
“after_create” method which calls a method in a child model that it
has. It is THIS method which is not being called. I have printouts
before and after everything, like I said, and the lines before and
after the method call work, which leads me to believe that method IS
getting called. However I have a “puts ‘foo’” at the top of that
method and it doesn’t get printed.

The object is not nil, and it has even been successfully saved
previously in the code, and all of its necessary attributes have been
set. Why on earth is it not getting called? Keep in mind, it DOES
get called if I run “spec” on that specific file. If I run it among
my other spec files (I’ve got lots) it DOES NOT get called.

I need some ideas on how to chase this one down? I stuck printouts
everywhere to track the issue down as narrowly as I have but I’m down
to a single line and it’s doing something I didn’t even know was
physically possible in this language. It seems I must be overlooking
something but I just can’t seem to see outside of the box on this
issue. Any ideas would be great, thanks!

Glenn

On Nov 14, 2007, at 11:37 AM, Glenn F. wrote:

I run my suite of tests, one test fails.
I run that one test file, no tests fail.

Something is carrying over between files and I can’t figure out what.
I tracked down the problem to the very line it’s occurring on, with
printouts before and after every call to make sure I know exactly what
is being reached.

First of all - make sure you don’t have any after(:create) or before
(:create) specs. If an AR object is created in one of these, it IS
NOT
going to be rolled back.

You might also try the following:

rake db:migrate; rake db:test:prepare

Log into mysql (or whatever database) - inspect it to see that no
records are present in your test database (if you really aren’t using
fixtures at all).

getting called. However I have a “puts ‘foo’” at the top of that
method and it doesn’t get printed.

You might want to try running that one spec with the following
snippet stuck into the top of your after_create method:

require ‘rubygems’; require ‘ruby-debug’; debugger;

When the spec runs, you will be dropped down into the ruby debugger,
so you can inspect what is actually going on. (You will need to
know how to use a debugger, and have the ruby-debug gem installed).

If that doesn’t yield any helpful information, then remove that
snippet and put it at the top of the failing test (the first line of
the example (“it”) block). Then run the full test suite, and again,
you will be dropped down into the debugger.

Hope that helps,

Scott

Your suggestion put me on the right track. I looked back to where I
had I ran into a case where I was trying to stub an instance I
couldn’t get ahold of in the scope of my spec and since I was having
trouble with some mocha bugs, I resorted to a
Model.class_eval do
alias_method :original_method, :old_method
end

Unfortunately I didn’t set the alias back at the end of the spec.
That was my problem. Thanks a ton!

Glenn

On Nov 14, 2007, at 2:14 PM, David C. wrote:

model = Model.new

(class << model).class_eval do
alias_method :original_method, :old_method
end

That way it can’t leak to other instances of the same model.

That’s what I had hoped to do, but as I stated in my description, the
difficult situation involved a model I couldn’t get ahold of in the
scope of my spec. If I was able to instantiate it somehow myself I
would have just stubbed the method. This probably means I’ve got some
code in the controller that shouldn’t live in the controller,
however. If I refactor it properly I doubt I’ll need any more fancy
tricks like this. Thanks!

On Nov 14, 2007 1:07 PM, Glenn F. [email protected] wrote:

Your suggestion put me on the right track. I looked back to where I
had I ran into a case where I was trying to stub an instance I
couldn’t get ahold of in the scope of my spec and since I was having
trouble with some mocha bugs, I resorted to a
Model.class_eval do
alias_method :original_method, :old_method
end

Try doing that on the instance instead.

model = Model.new

(class << model).class_eval do
alias_method :original_method, :old_method
end

That way it can’t leak to other instances of the same model.