Does anyone test errors in their specs?

Rails
1

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?

2

Anthony S. 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,

Marnen Laibow-Koser
http://www.marnen.org
[email protected]

3

On Mon, Nov 8, 2010 at 5:01 PM, Anthony S.
[email protected]wrote:

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

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.

4

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?

5

On Nov 8, 2010, at 3:28 PM, Anthony S. wrote:

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.

6

Philip H. wrote in post #960209:

On Nov 8, 2010, at 3:28 PM, Anthony S. wrote:

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
http://www.marnen.org
[email protected]

7

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

8

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”.

Best,

Marnen Laibow-Koser
http://www.marnen.org
[email protected]