Yeah. But that's okay, since both testing layers (integration vs controller tests) verify different aspects. Integration tests are very slow, so I use them only for checking that all the different parts of the system are properly plumbed together ("integrated"). Running the full, end-to-end happy path in an integration test verifies this, and also that the main functionality of the feature actually works in reality. End-to-end test means you verify that the data and logic correctly flows through the whole stack.

Controller tests, on the other hand, are on the level of the individual component. They test the component itself, as well as all the different aspects and corner cases of its internal workings. I use controller tests to test the correct function of the component, as well as edge cases like authorization errors or missing data errors etc. They can also be used to test more varieties of handling correct data, for example how data is formatted in detail. This might result in some redundancy, but this is okay since we are testing on two different levels. 

The overall workflow is (roughly speaking)
* write the integration test first
* the integration test fails with an unknown route. Create the route and run the test again.
* the integration test fails with an unknown controller action. Create the controller action and run the test again. Creating controller action means create controller tests, see them fail, then write the code to make them pass. Write more controller tests for all the stuff that the controller is supposed to do. If you need model functionality, TDD this as well (write model tests, then code to make them pass). When all model tests pass, go back up to the contoller test and make the remaining ones pass. When all controller tests pass, go back up to the integration test, and run it again.
* the integration test fails with a missing view. Create the view and run the test again.
* the integration test fails with a missing button to click on the page. Add the button to the view and run the test again.
* the integration test fails because clicking on the button doesn't do anything. Add the click handler to the button. Creating the button handler logic means write clientside unit tests for the click handler, and then the button click handler. When done, run the integration test again. 

This way, the integration test always tells you what's next to do, and from the level of integration test you dive deeper into the code hierarchy to add missing functionality, and then go back to the integration test level. Doing it this way breaks up a complex problem into small pieces, which are quick and easy to solve. The development happens on tracks, you always make progress, you always know what's going on, you always have fun, you catch bugs right when you write them, and you are heading straight towards the finish line.