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?