Move sad paths out of feature specs

feature are slow

Feature specs are slow. They have to boot up a fake browser and navigate around.
They’re particularly slow when using a JavaScript driver which incurs even more
overhead. While you do want a feature spec to cover every user facing feature of
your application, you also don’t want to duplicate coverage.

Many times, feature specs are written to cover both happy paths and sad paths. In
an attempt to mitigate duplicate code coverage with slower tests, we’ll often write
our happy path tests with feature specs, and sad paths with some other medium,
such as request specs or view specs. Finding a balance between too many and too
few feature specs comes with experience.