I can’t figure out what is causing this problem. I’m using the latest
rspec
and rspec-rails gems on rails 2.3.2.
When I run autospec, the tests in the model spec that I am editing will
all
fail. The error messages are like this:
ActiveRecord::RecordInvalid in ‘Job new record should create a new
record
given valid attributes’
Validation failed:
(Nothing after Validation Failed:, just blank). It doesn’t matter what
attributes I pass to create the new model, and it doesn’t matter if I do
it
using a regular create! method or using Machinist, the same error
happens.
Now, if I make a change, autospec will run the specs from that one model
spec again, and they will all pass. Then it runs all of my specs again
and
that’s when the specific spec I’m editing fails (only when it runs all
the
specs). When I run rake spec:models or rake spec:controllers, everything
passes as it should. So I figured it might have something to do with the
controller specs, and if I remove those, autospec passes again. Then if
I
put the controller specs back, autospec still passes. It only starts
failing
if I again edit the model specs.
This is happening in multiple models, not just one. It’s making it
impossible to work with, so I’d really appreciate any thoughts you might
have. Thank you!
–
View this message in context:
http://www.nabble.com/autospec-fails-but-rake-spec-tasks-pass-tp22746792p22746792.html
Sent from the rspec-users mailing list archive at Nabble.com.
I figured out what the problem was. Turns out that the controller specs
used
Mocha’s any_instance method to stub valid? and return false (I got this
idea
from a Railscast). Due to the order in which autospec runs the specs,
editing the model spec was causing it to be run after the controller
spec,
and the Mocha stubs were still being applied in the model specs. I’m not
sure if I was doing something wrong, if there is some way to ‘clear’ the
stubbed methods that would be great, or perhaps I just shouldn’t use
any_instance.
View this message in context:
http://www.nabble.com/autospec-fails-but-rake-spec-tasks-pass-tp22746792p22763942.html
Sent from the rspec-users mailing list archive at Nabble.com.
On Sat, Mar 28, 2009 at 11:05 PM, jakepaul [email protected] wrote:
I figured out what the problem was. Turns out that the controller specs used
Mocha’s any_instance method to stub valid? and return false (I got this idea
from a Railscast). Due to the order in which autospec runs the specs,
editing the model spec was causing it to be run after the controller spec,
and the Mocha stubs were still being applied in the model specs. I’m not
sure if I was doing something wrong, if there is some way to ‘clear’ the
stubbed methods that would be great, or perhaps I just shouldn’t use
any_instance.
I haven’t seen the railscast to which you refer, but if you’re using
mocha instead of rspec’s mock framework, be sure to configure that in
spec_helper.rb (or anywhere that gets loaded before the specs run):
Spec::Runner.configure do |config|
config.mock_with :mocha
end
If you do that, then the mocha stubs and expectations should get
cleared out after each example runs, eliminating the ordering
dependency that is causing you trouble.
Cheers,
David
On Mon, Mar 30, 2009 at 10:48 AM, Scott T. [email protected]
wrote:
fail. The error messages are like this:
Now, if I make a change, autospec will run the specs from that one model
impossible to work with, so I’d really appreciate any thoughts you might
…
end
Or, if you’re using rspec-1.2.2, just:
it “should …” do
debugger
and then use the --debugger option on the command line 
Cheers,
David
On Mar 27, 2009, at 4:38 PM, jakepaul wrote:
record
model
put the controller specs back, autospec still passes. It only starts
failing
if I again edit the model specs.
This is happening in multiple models, not just one. It’s making it
impossible to work with, so I’d really appreciate any thoughts you
might
have. Thank you!
Your problem is one of load order.
I’d suggest running the debugger at the start of your failing spec:
it “should …” do
require ‘rubygems’; require ‘ruby-debug’; debugger
…
end
Run the specs in the failing case, and debug from there.
Scott