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