top of page
  • Writer's picturePrashant Bellad

You can reuse the same user login across E2E automation tests


A few of the basics of test automation to achieve robust tests are:


  • Tests should be small, fail fast and should not assert multiple things

  • Tests should execute independently of each other and with fresh application state


To achieve the above, we should:


  • Create a fresh new user for each test

  • Reset the user data and application state before each test


Still, there would be cases where you would want to reuse the same user login across tests…

Below are some of the examples:


  • When all these tests share the same application state

  • Any edits or addition to the application state in a test is not referenced or used in other tests

  • When you want to break a long test having a bunch of assertions into smaller tests with each test responsible for asserting individual checks. This approach helps avoid missing test assertions in case of failures. eg a test having 3 assertions A, B and C and if the test fails at assertion A then this instance of test would never execute B and C


What can be a real-world use case for using the same user login?

Let's say there is a school web application that has a Teacher Management page.


  • This page lists all the teachers teaching in the school

  • A teacher can teach one or more classes across morning or afternoon shifts

  • Teachers have designations and other roles


You want to create test cases to validate if the teacher filter functionality is working as expected on the Teacher Management page. Below can be relevant test cases:


  • Validate that by default 50 teachers are listed on the page

  • Filter by kindergarten teachers should only list teachers teaching kindergarten classes

  • Filter teachers who have joined in the present academic year

  • Filter teachers who teach math


Now let's verify if the above test cases satisfy our criteria for reusing the same logged-in user across tests


  • All these tests share the same application state —> ✅ We can reuse the same teacher's data across tests

  • Any edits or addition to the application state is not referenced or used in any other tests —> ✅ The tests are read-only as we are not updating any application state or data.

  • When you want to break a long test having a bunch of assertions into smaller tests with each test responsible for asserting individual checks. —> ✅ We are separating filters tests into independent test


When should you try to avoid reusing the user even if your use case satisfies the above criteria?


  • Avoid it if you are splitting the tests across spec files because

  • The user would be set up in the test from the 1st spec file and the subsequent spec file would then become dependent on the 1st spec file (even if the tests across spec files are still independent)

  • This would cause conflict issues when you execute these spec files in parallel


Advantages:


  • Makes the test execution quicker as we do not have to re-create the user and the application state

  • Makes the test pass or fail fast

  • Help in making the tests more robust



Hope you find the article an useful resource. Do share your feedback with me at hello@PristineProtech.com, visit www.PristineProtech.com to know more about our offerings and services...

11 views0 comments
bottom of page