I test at controller level that things aren't accessible (security) and at integration level that the appropriate things are accessible and error messages are correct when not (functionality).
Yup, the real best practice is to use your judgement and choose the right test for the job.
If it's something that you can see in a browser (and the results are visible too), then it's a candidate for an integration spec.
You really shouldn't be integration testing stuff like security. For example, testing a user can't submit a form they can't see (which is where horrible Rake::Test::Methods mixin hacks start appearing).
You also shouldn't (imho) be integration testing side effects that aren't visible to the user. For example, if an action ends up in an audit log that the user is never going to see, there's no point firing up an integration test to do that. A light-weight controller test can do that just fine.
If it's something that you can see in a browser (and the results are visible too), then it's a candidate for an integration spec.
You really shouldn't be integration testing stuff like security. For example, testing a user can't submit a form they can't see (which is where horrible Rake::Test::Methods mixin hacks start appearing).
You also shouldn't (imho) be integration testing side effects that aren't visible to the user. For example, if an action ends up in an audit log that the user is never going to see, there's no point firing up an integration test to do that. A light-weight controller test can do that just fine.