Does anyone test errors in their specs?

For example:

it 'should not validate if nil' do       @account.name = nil       @account.should_not be_valid       @account.errors[:name][0].should eq 'can\'t be blank' end

Is this good practice?

Anthony Smith wrote in post #960202:

For example:

it 'should not validate if nil' do       @account.name = nil       @account.should_not be_valid

Those two lines are good practice: you're testing that the object is invalid when you want it to be.

      @account.errors[:name][0].should eq 'can\'t be blank'

That line seems unnecessary: you're testing the Rails framework, which is already well tested.

end

Is this good practice?

Best,

For example:

it ‘should not validate if nil’ do

  @[account.name](http://account.name) = nil

  @account.should_not be_valid

  @account.errors[:name][0].should eq 'can\'t be blank'

end

I do - my discipline is whenever I am modifying a model I will write my outcomes first - and it does tend to find problems, especially when things start getting more complex.

My thought is that it verifies you're receiving the error you expected and not an artifact from another issue. So my intention is not to test Rails but to make sure my tests are doing what I'm expecting. Does that make sense or am I just paranoid?

My thought is that it verifies you're receiving the error you expected and not an artifact from another issue. So my intention is not to test Rails but to make sure my tests are doing what I'm expecting. Does that make sense or am I just paranoid?

Both :slight_smile: Instead of testing the specific error message which could change you could test to make sure there is N (or at least N) number of errors on @account.name. That would solve your issue of it being invalid for some unrelated reason.

Philip Hallstrom wrote in post #960209:

My thought is that it verifies you're receiving the error you expected and not

an artifact from another issue. So my intention is not to test Rails but to make sure my tests are doing what I'm expecting. Does that make sense or am I just paranoid?

Both :slight_smile: Instead of testing the specific error message which could change you could test to make sure there is N (or at least N) number of errors on @account.name. That would solve your issue of it being invalid for some unrelated reason.

That's still testing Rails instead of your code. Instead, here's what I do:

before :each do   @account = Account.make # from a factory with valid values end

it "should be valid with valid values"   @account.should be_valid # now we have our baseline end

it "should not be valid without a name"   @account.name = nil   @account.should_not be_valid end

...and so on. This is the best stolidity I've been able to figure out.

Best,

Marnen Laibow-Koser wrote in post #960256: [...]

This is the best stolidity I've been able to figure out.

iPhone autocorrect strikes again. I meant "atomicity", not "stolidity".

Here is my way:

require 'mocha' require 'shoulda'

should "not be valid without a name" do   @account.name = nil   @account.errors.expects(:add).with(:blank)   @account.valid? end

Testing messages is clumsy (especially with i18n) so I started testing that proper error was added (not propert message generated).

Robert Pankowecki