Java – cucumber, repeat the login step for all scenarios

I use Selenium with cucumber (using JAVA, but not much relevance).

Let’s say I have the following scenario:

Feature: Sample Feature

Scenario: do action A on website Given website is opened And
user put correct login and pass in fields And user press login
Then do action A

Scenario: do action A on website Given website is opened And
user put correct login and pass in fields And user press login
Then do action B

There are now hundreds of scenarios where websites always need to log in, so I’m assuming I’ll have to repeat the login step for each test scenario (e.g. via a BACKGROUND or before scenario hook).

I’ve been reading that this kind of testing should be autonomous, so webdriver instances should not be shared between scenarios

Say:

Features: Some characteristics

Scenario: Log into website first
Steps…

Scenario: Do action A (while we are logged already
Steps…

Scenario Do action B (all the time in same browser instance we used in
login step and action A step
Steps…

But I’ve found that some people say this is the wrong approach, but repeating the login process every time I want to do some test scenarios takes a lot of time running many scenarios, and each scenario requires logging in first. I am thinking of enabling the possibility of accessing the website without logging in for testing, is there any recommended way? Thank you.

Each scenario that requires a user to sign in requires a user to sign in. This is part of the cost of running at the integration level. However, logging in shouldn’t be an expensive time-consuming operation, you only need to fill in two fields and submit. It should take < 100 milliseconds to process the login.

Now for unit testing, this time is huge, but for integration testing, it essentially involves a larger stack and often simulates human-computer interaction (why would otherwise require a user login) this time a relatively small component overall scenario run time.

Because Cucumber works at the integration level, it’s best not to use it as a testing tool, but rather as a tool to drive development. Instead of writing thousands of small assertions (as you might when unit testing), write fewer large scenarios, i.e. more things need to be done per scenario. As each scenario does more and more, so does the need for each scenario to be completely independent of any other scenario (the more you do, the more likely you are to have side effects on other things that have been done). Sharing sessions and trying to avoid resetting the database and session between each scenario turned out to be the wrong optimization, creating more problems than it solved.

It’s great for a scene to do a lot of things before you get to its time. For example, imagine the following e-commerce scenario.


Scenario: Reorder Collection clips
Given that I have a favorite order
When I view my order
I reorder my favorite order
Then I should be taken to the cash register
My favorite thing should be in the basket


It’s now clear that a lot needs to be done before I can reorder

• I need to register
• I need at least the next order
• I need to choose a favorite order

Of course, there are many other things

• Need to have a product to order

All of this

means that this scenario takes time to run, but that’s okay because you get a lot out of it. (When I wrote something like that a long time ago, it took 1-2 seconds for the scene to run). The login time in this case is negligible compared to the time it takes to complete the rest of the setup.