I am using selenium with cucumber (using JAVA, but not much relevant)
Let's say I have following scenarios:
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 AScenario: 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
Now, there will be hundreds of scenarios, and website always require to log in into the website, so I assume for each test scenario I will have to repeat login steps (for example by BACKGROUND or before scenario hook)
I have been reading that this sort of tests should be autonomous, so there should be no sharing of instance of webdriver between scenarios
Say:
Feature: Some feature
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 found people saying its not correct way, but repeating login procedure everytime I want to perform some test scenario takes a lot of time during runing many scenarios and each needs to log in first. I was thinking about enabling possibility to access website without login for testing purpose, is there any recommended approach? Thank you.
Every scenario that requires a user to be logged in will need to have the user log in. This is part of the cost of running at the integration level. However log in should not be an expensive time consuming operation, you only have to fill in two fields and submit them. It should take < 100ms to process the login.
Now for unit testing this time is huge, but for an integration test, which by its nature involves a much bigger stack and usually simulated human interaction (otherwise why do you need your user to login) this time is a relatively small component of the overall scenario run time.
Because Cucumber works at the integration level it is best not to use it as a testing tool, rather it should be used as a tool to drive development. Instead of writing thousands of small assertions (like you might when unit testing) you need to write fewer larger scenarios i.e. each scenario needs to do more. As each scenario is doing more the need for each scenario to be completely independent of any other scenario increases (the more you do, the more likely you are to be side effects on other things that are done). Sharing sessions and trying to avoid resetting the db and session between each scenario turns out to be a false optimization that creates more problems than it solves.
Its perfectly fine for a scenario to do alot before you get to its when. For example imagine the following e-commerce scenario.
Scenario: Re-order favorite
Given I have a favorite order
When I view my orders
And I re-order my favorite order
Then I should be taken to the checkout
And my favourite items should be in the basket
Now clearly an awful lot of stuff needs to happen before I can re-order e.g.
and of course there are lots of other things like
All of this means that this scenario will take time to run, but thats OK because you are getting alot of functionality from it. (when I wrote something similar a long time ago, the scenario took 1-2 seconds to run). The login time for this sort of scenario is trivial compared to the time required to do the rest of the setup.