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???
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.”
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.
On Tuesday, January 11, 2011 12:41:54 PM UTC-5, Ruby-Forum.com User
wrote:
it “should set the value to 2” do
I believe David C. (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:
On Tuesday, January 11, 2011 12:41:54 PM UTC-5, Ruby-Forum.com User
wrote:
it “should set the value to 2” do
I believe David C. (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:
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.
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?
If you use the non-bang version of save, the spec passes. IE:
p.save
instead of
p.save!
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?
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.