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...
Comments