1

We have a Cucumber BDD test project using C# Specflow. The application is browser based tested using Selenium WebDriver automation framework.

There are a number of feature files with scenarios:

Customer.feature

@regression @smoke
Scenario: Create_Customer
Given i have logged in with user 'admin' and used the 'TestDB1' database
And i click on the Customer page

@regression
Scenario:Edit_Customer
Given i have logged in with user 'admin' and used the 'TestDB7' database
And i click on the Customer page

Employee.feature

@regression @smoke
Scenario:Create_Employee
Given i have logged in with user 'admin' and used the 'TestDB1' database
And i click on the Employee page

@regression
Scenario:Edit_Employee
Given i have logged in with user 'admin' and used the 'TestDB2' database
And i click on the Employee page

Each scenario currently logs in, selects a database from the login page and then logs out at the end of the test. Test runs use the tags to select the scenarios. Tests are not in parallel atm.

The login process (the 'Given' step) takes 30 seconds per scenario.

It's been requested that it's changed so we only login once and then stay logged in for the duration of the test run using the same browser session, UNLESS a different database is then required on the next scenario in which case it should logout and then login using the new database. So a hypothetical run with no control of run order:

Scenario:Create_Customer starts and logs in selecting 'TestDB1' and stays logged in.

Scenario:Create_Employee starts doesnt login as the database is set to 'TestDB1' and stays logged in.

Scenario:Edit_Customer starts, needs a different db and so logs out and logs back in selecting 'TestDB7' etc..

There is nothing visible in the application to show what database was selected at login. Any idea what approach could be considered across multiple features in a test run? From the sound of it, I need to somehow perpetuate a "database" value and "currentlyLoggedIn" value (or identify the application is still open) across the test run but obviously can't use the ScenarioContext/FeatureContext.

I appreciate this is not a good idea as test independence should be maintained but surely other people have considered reducing the repeated logins? If this really shouldn't be done, any suggestions on how to save this 30+seconds per test?

1

I don't recommend reusing sessions but you could do the login as part of your [OneTimeSetUp]/[AssemblyInitialize] in your test class and likewise [TearDown]/[AssemblyCleanup] the session (what you use depends on the 'Custom Tool' set on your .feature file). You can save what ever you want as a global like I outlined on a similar question.

I did this once for mobile testing using Appium (so I didn't lose my device slot on SauceLabs's TestObject) and if you do the same remember to wrap the first call to the session with a try/catch or something to create a new session if the stored one timed out or crashed.

-- Edit Below --

I incorrectly said [OneTimeSetUp] which is true if not using SpecFlow. When using SpecFlow the equivalent would be [BeforeTestRun]/[AfterTestRun].

5
  • Thanks i'll look at this, any particular reason why you feel reusing sessions is not recommended (I'll be asked no doubt). – m_finn Dec 8 '20 at 20:13
  • 1
    FIRST properties of unit tests recommends isolation and repeatability. Reusing a session carries the risk of the session being terminated, having extra session data, and being hard to reproduce manually in some cases. This is not a hard line rule as you see in my answer that I have had to reuse sessions when working with mobile device farms. – kirbycope Dec 8 '20 at 22:15
  • Thanks @kirbycope I'm having some trouble with the solution you pointed to for perpetuating data between scenarios . If i create a global class with a number of variables and all the step definition files inherit from global. Once a scenario is completed and the new one starts the variables are all nulled like the binding files have been re-instantiated. It might be something to do with the framework architecture (using Specflow) but i cant find a way of perpetuating data across the whole test run. – m_finn Dec 15 '20 at 15:01
  • 1
    You should try using DataHelper.cs that has the public WebDriver variable and in [OneTimeSetUp] you create your session. For the tests, they can inherit from a base test class so you don't have to do the same step for each test of checking the session before using it, just do that once in the base class' [SetUp]. – kirbycope Dec 16 '20 at 16:20
  • Thanks - really appreciate this, got it working. My knowledge of programming is a hindrance but learnt a lot from your advice. – m_finn Dec 17 '20 at 14:12
1

I would go with different features.

CAN you go with DB1.feature doing everything and then DB7.feature? Can you create employee and customer in one run on the same DB?

3
  • Yes they could devote specific databases to features instead of having multiple db's in each feature. This is just the way the tests have evolved with each database having different datasets from different contributors (testers). You can create employees and customers from the same db but there is multiple db's as the preloaded datasets needs to be in different states for some of the tests and also to prevent changes made in scenarios impacting other scenarios that need to run. – m_finn Dec 8 '20 at 8:35
  • 1
    So that would help with login only once, wouldn’t it? :) – Michal Dobrzycki Dec 8 '20 at 10:17
  • Yes it would, if possible I'm trying to find a solution where i don't invoke restrictions on the scenario writers as to how they build their datasets by specific feature but this may be a preferred way forward. – m_finn Dec 8 '20 at 20:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.