[oesmith]

I really don't like the idea of "no controller tests at all" as a best practice.

If you're having to mixin Rack::Test::Methods to write your "full-coverage" integration spec, then you're really writing a controller test. It should go in a controller spec without all the horrid mixin hacks.

[josephlord]

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

[oesmith]

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.