views:

17

answers:

1

When running one of my app's functional tests the other day I hit a bug in my code that was causing a RoutingError. My functional test was loading a page and in that page it was creating a link to a page that had no valid route to it. The specific cause of the exception is not the point though - the problem was that this exception was not passed back to my test. The only reason I know the exception occurred was because I happened to notice it in the test.log file. In short the test passed but I think that should count as a fail!

This confused me. I tried putting my test code in an assert_nothing_raised block but it still passed.

Digging further I came to realise that any exception thrown by my app was being silently logged and not causing tests to fail. Is this intentional behaviour in Rails or does it sound like I've got something set up wrong?

EDIT: I think the problem might be that Rails catches and handles the exception (so that it can present the familiar stack-trace page when the request is sent from a browser). I can see why this is useful in the development environment, but surely not in the test environment...?

A: 

You should be explicitly checking the response of each action in your functional tests, try doing something like this instead:

get :index assert_response :success

you should always have some form of assertion for the response. When the action is supposed to redirect you use assert_redicted_to

Jeremy
That helped me track it down Jeremy. The problem appears to be a difference between the way functional tests and integration tests handle exceptions. (I had misrepresented by problem a little - it's actually an integration test that fails.) If you call `get '/boom'` in an _integration_ test you get no exception, just a `500` response. In a _functional_ test however, the `get` itself raises the exception. Odd.
Ben
Ah, glad I could help. I didn't actually know that about integration tests, good to know
Jeremy