strange rspec problems checking model validations

Hi all,

I am experiencing a very strange problem using RSpec. I have a very basic rails3 app, using devise and mongoid. Following code:

# postcard.rb class Postcard   include Mongoid::Document   field :text, :type => String   validates_presence_of :text end

# postcard_spec.rb require File.dirname(__FILE__) + '/../spec_helper' describe Postcard do   it {should validate_presence_of(:text)}   it "should validate presence of text" do     p = Postcard.new     p.save!     p.errors.include?(:text).should be_true   end end

Now, what happens, is that the tests (the shoulda one and my own one) fail. The Postcard is saved without any warnings or error messages (also verified by Postcard.count, which is 0 before save! and 1 afterwards. BUT when I do the exact same code in any controller_spec it works as expected. Same when I do it on the console. And the validations also work in the normal app.

So what the heck is wrong with my postcard_spec.rb???

The validation works for me: http://pastie.org/1448752

If you use the non-bang version of save, the spec passes. IE: p.save instead of p.save!

BTW, it’s best not to include the word “should” in your spec descriptions. it ‘validates the presence of “text”’ do is better because it’s more descriptive.

The word “should” is soft; it doesn’t mean “fail if this isn’t true”, which is what we’re trying to convey.

Nick Hoffman wrote in post #973978:

BTW, it's best not to include the word "should" in your spec descriptions.     it 'validates the presence of "text"' do is better because it's more descriptive.

I don't agree. Since RSpec's syntax uses "should" as a technical term, I believe it should be in every spec description:

it "should set the value to 2" do   value.should == 2 end

The word "should" is soft; it doesn't mean "fail if this isn't true", which is what we're trying to convey.

"Should" as an RSpec technical term isn't soft at all. It's "this *should* be true. If it is not, we have a problem."

Best,

I believe David Chelimsky (the original/primary author of RSpec) specifically said that spec descriptions should not begin with “should”. I tried to find where he wrote that, but wasn’t able to. However, take a look at David’s examples:

http://blog.davidchelimsky.net/2010/11/07/specifying-mixins-with-shared-example-groups-in-rspec-2/ http://blog.davidchelimsky.net/2010/06/14/filtering-examples-in-rspec-2/ http://blog.davidchelimsky.net/2009/09/15/let-it-be-less/

None of those posts have “should” in a spec description.

The latest example on David’s blog that uses “should” in a spec description is from 2008: http://blog.davidchelimsky.net/2008/07/01/new-controller-examples/

However, this convo should be moved to the RSpec mailing list.

Nick Hoffman wrote in post #974004:

it "should set the value to 2" do

I believe David Chelimsky (the original/primary author of RSpec) specifically said that spec descriptions should not begin with "should". I tried to find where he wrote that, but wasn't able to. However, take a look at David's examples:

http://blog.davidchelimsky.net/2010/11/07/specifying-mixins-with-shared-example-groups-in-rspec-2/

http://blog.davidchelimsky.net/2010/06/14/filtering-examples-in-rspec-2/ http://blog.davidchelimsky.net/2009/09/15/let-it-be-less/

None of those posts have "should" in a spec description.

And virtually none of them use .should for anything in the steps. Note the symmetry.

The latest example on David's blog that uses "should" in a spec description is from 2008: http://blog.davidchelimsky.net/2008/07/01/new-controller-examples/

Interesting (especially since I've been using RSpec since before 2008). I maintain that the older style is clearer, since 'it "adds 2 to foo"' is misleading: it *should* add 2 to foo, but we don't know whether it *does* until we run the test.

However, this convo should be moved to the RSpec mailing list.

Yeah, probably.

Best,

At the end of the day, there’s no right or wrong in this discussion. It comes down to what terminology is most appealing for you.

It makes no difference, whether I use the bang or the non-bang version. Both ways it fails. Especially the shoulda spec one-line test should work, but doesn't. And as I said, the strangest thing of all is, that the test works as expected (passes) if I put it in any controller spec for instance (not the shoulda one, of course). So my code must be correct (since rails itself works as expected and the console works as expected) BUT only this very spec in that spec file doesn't work at all. And that's the thing, I have absolutely NO clue at all, what might be the reason for that. To me, it looks like a bug in some of the components I'm using or their interaction. But then, it is such a simple test, I can hardly believe a bug like this would slip through undetected. So yeah... any further suggestions?

OK... I know the problem now:

My spec_helper.rb was configured with: config.mock_with :rspec

and a controller_spec is using Postcard.any_instance.stubs(:valid?).returns(true)

Obviously this stub wasn't properly reset after that one controller spec, that uses it. So it screwed up my Postcard specs. I switched to using mocha now, and all tests pass as expected.

But one question remains: Why didn't this stub get reseted automatically after each spec?