When to use Cucumber and when to use RSpec?

I use RSpec to drive the development and testing of my models and to some extent my controllers, and Cucumber to drive the development and testing of my views (and subsequently their integration with the controllers).

I don't feel writing Cucumber tests allows me to "skip" writing RSpec tests because a lot of development takes place in the model layer before any views are created.

If you keep writing Cucumber scenarios instead of unit tests, then you will probably find that your tests become very slow to run. If the tests are slow, you probably won't run them very often, so your development pace will slow down.

You can use RSpec for integration tests operating at the same level as Cucumber. If you need to share and discuss features with non-developers, then Cucumber is a huge help. But even if you're a solo developer, Cucumber helps by acting as a 'mental guard' between the behaviour you need and the underlying implementation.

The standard practice most people follow is to write extensive unit tests for the model, minimal tests for the controller, and very rarely any unit tests for the view. Then you would use Cucumber to check everything is interacting properly (be sure that you scenarios cover any loops/conditions in the controllers and views).

I'm not sure if it's OK to recommend a book here, but The RSpec Book by David Chelimsky (ISBN 9781934356371) does provide a nice practical example of how Cucumber and RSpec can be interleaved to behaviour-drive the development of a small command-line game in Ruby.

In a nutshell: writing your Cucumber features adopting the point of view of your end-user, and your RSpec specs using your own point of view as a developer is a good balance between execution speed of the test suite, testing granularity (how precise are the error messages when your tests fail) and documentation coverage (the Cucumber features can be seen as an always up-to-date documentation - the very own RSpec documentation is a great example of that).