You can use Cucumber in a lot of different ways. You can use it as an acceptance test, an integration test. Usually you it's a mixture of both.
There are a lot of right and wrong ways to write Cucumber tests in my opinion. I think I have been writing Cucumber tests the wrong way until now and I am trying to improve that.
Here is the thing:
When it is evidently clear a user will have to log in for your app I think you should not include a step like that in your Cucumber test. To illustrate, instead of:
Scenario: View stock for a regular product
Given there is a product
When I log in
And I go to the product
Then I should see the product's total available stock
Write this:
Scenario: View stock for a regular product
Given there is a product
When I go to the product
Then I should see the product's total available stock
If you are writing Cucumber tests (and I can think of a lot of reasons why you would or you shouldn't) I think you should keep them as implicit as possible from your standpoint as a user.
If you're a regular user of the software you are writing, it's pretty obvious you need to log in if you need to do that for every action you are going to take in the application. Especially when it's some kind of business backend administration kind of app where there is no public facing page.
I do think you should create features like "Log in" and "Create account" to test those particular paths in your application.
However, when looking at the sample above, I think it's better to write a step like:
When /$I go to the product$/ do
step "I log in"
visit product_path(@product)
end
Maybe a good rule of thumb could be: When collaborating with a designer or sketching out a feature and explaining it to other people, would you actually draw out the logging in part? Or would you take that as out of scope for the sketch/mockup you are writing and assume it is obvious.