Catching StandardError

Watch out if the code you're testing catches StandardError (of course you're not catching Exception, right?). Try this:

Nothing particularly exciting there. Let's run it and check that it passes:

$ spec foo.rb
.

Finished in 0.001862 seconds

1 example, 0 failures

However, what if we change the example to test the opposite behaviour?

$ spec foo.rb
.

Finished in 0.001865 seconds

1 example, 0 failures

Wait, surely they can't both pass? Let's take out the rescue and see what's going on:

$ spec foo.rb
F

1)
Spec::Mocks::MockExpectationError in 'Calling a method that catches StandardError does NOT call Bar.bar'
 expected :bar with (no args) 0 times, but received it once
./foo.rb:6:in `foo'
./foo.rb:18:

Finished in 0.002276 seconds

1 example, 1 failure

That's more like it.

Of course, what's really happening here is that Spec::Mocks::MockExpectationError is a subclass of StandardError, so is being caught and silently discarded by our method under test.

If you're doing TDD properly, this won't result in a useless test (at least not immediately), but it might cause you to spend a while trying to figure out how to get a failing test before you add the call to Foo.foo (assuming the method with the rescue already existed). Generally you can solve the problem by making the code a bit more selective about which exception class(es) it catches, but I wonder whether RSpec exceptions are special cases which ought to directly extend Exception.

Checking receive counts on previously-stubbed methods

It's quite common to stub a method on a collaborator in a before block, then check the details of the call to the method in a specific example. This doesn't work quite as you would expect if for some reason you want to check that the method is only called a specific number of times:

$ spec foo.rb
.

Finished in 0.001867 seconds

1 example, 0 failures

I think what's happening here is that the mock object would normally receive an unexpected call, causing the expected :bar with (any args) once, but received it twice error that you'd expect. Unfortunately the second call to the method is handled by the stub, so never triggers the error.

You can fix it, but it's messy:

$ spec foo.rb
F

1)
Spec::Mocks::MockExpectationError in 'Checking call counts for a stubbed method only calls a method once'
 expected :bar with (any args) once, but received it twice
./foo.rb:23:

Finished in 0.002542 seconds

1 example, 1 failure

Does anyone know a better way?

The full example code is in this gist.

Obviously it failed, as I hadn't written the code yet, but there was more in the error message than I expected:

..........F

1)
RuntimeError in 'Blog should not mass-assign 'confirmed''
'should_not be  true' not only FAILED,
it is a bit confusing.
It might be more clearly expressed in the positive?
.../spec/models/blog_spec.rb:20:

Finished in 0.06192 seconds

11 examples, 1 failure

In fact, rewriting this as should be_false wouldn't work, as the expected value is nil. I took the hint though, and rewrote it as should be_nil.

You have to declare the controller name in controller specs. For example:
describe "The ExampleController" do
controller_name "example" #invokes the ExampleController
end

The problem seemed to depend on which order the specs were run in, and for rake it could be avoided by removing --loadby mtime --reverse from spec.opts. It was a real pain with autotest though, and today (my original plan of "wait for RSpec 1.1 and hope it goes away" having failed) I finally got round to looking into it properly.

It seemed that the error was being triggered by the rather unpleasant code I wrote a while ago to simplify testing of model validation. Digging into the RSpec source to see what was happening, I found that that error message only gets returned when (as you'd expect) you don't declare the controller name in a controller spec (specifically in an instance of Spec::Rails::Example::ControllerExampleGroup). The code that decides what type of example group to create lives in Spec::DSL::BehaviourFactory, and according to its specs, there are two methods it uses to figure out what type of spec it's looking at:

I began to suspect that the problem was caused by the fact that my specify_attributes method wasn't declared in a file in spec/models, so I thought I'd try specifying the type explicitly. So instead of this:

I changed it to this:

Sure enough, it worked! Not sure whether anyone else is likely to see the same problem (unless they're foolish enough to use my validation spec code), but hopefully if you do, a Google search will bring up this post and it might point you in the right direction.