Selenium Test Design Struture - Test Granularity for a Large Project

Question

Summary

I have large Selenium Test project, and I'm struggling with how to manage my test structure in a way that I feel is easily maintainable, scalable, and that provides a good level of test granularity.

Setup

Currently my organization has great number of what I would describe as "Functional Tests" written in an excel document, with the following structure.

• Press button X -> Grid enters edit mode
• Attempt to add invalid value Y to field X in edit grid -> validation is shown...
• Delete item X by pressing... -> item is removed from the grid

These tests have been working well for our organization, but as our product increases in size we have decided to use Selenium to automate these tests. Following the Page Object Model and Selenium Best Practices I have converted these tests into several hundred(soon 1000's) of Selenium automated tests.

These tests are provide a high level of coverage and are at a good level of granularity, however when translated into automated selenium tests it soon becomes readily apparent that they have a large number of dependencies on each other. This then leads into questions like this one. Also if one dependency is broken, many later tests will fail for reasons not readily apparent to the test runner.

Current Design

What I've done to solve this issue of dependencies and run order execution is to structure my tests in the following manner:

• ClassInitialize(Each test class represents a page) - Create a Bunch of Test Object/Data to be Manipulated

• Test 1 - Access already create Test Object, navigate to subitem, create/edit/delete

• Test 2 - Access already create Test Object, test validation

• Test 2 - Access already create Test Object, create/delete

The tests can now be run in any order, they no longer have any dependencies on each other(only the data/objects created in the "ClassInitialize" class).

However, now I no longer have the granularity that I achieved with my hand written tests, as now, any time I interact with items that I didn't create in the setup step, I need to create and delete them just to test the edit functionality. Also the "ClassInitialize" class becomes huge and encompasses much of the functionality that I'm trying to test in the first place.

It seems by solving the issue of dependency I have introduced these new challenges. I wonder if any one else has faced a similiar problem, it seems to me that any complicated page with many selenium tests would have the same challenges, but unfortunately, the examples online that I can find never truely get to a scale where these questions are addressed.

Question

How do I structure my Selenium automated browser tests so that I can maximize the granularity without introducing complex dependencies?

Answer 1

My personal preferred Design Structure:

Using Page Object Model, create all of your actions for the webpages. I then use Specflow and tag those actions with a human-readable name. You can then write out your tests as Features using Specflow and keep the granularity of your current manual test cases via the feature files.

Instead of using Class Initialization steps, you can tag those as steps in Specflow (Given I have setup a x, when I do y, then z will happen). This also helps drastically with code reuse.

Since you have a database dedicated to this you can put delete scripts into hooks to sanitize your environment after each run.

---

Specflow Scenario

@rollback
Scenario: Active search does not return Inactive Campaigns
    Given I have the active Campaign count
    When I add an inactive Campaign
    Then I should have 0 more active Campaign

Specflow Step Definition

[Given(@"I have the (.*?) Campaign count")]
public void GivenIHaveTheAlertResolutionTypeCount(string inactive)
{
    bool active = true;
    if (!inactive.Equals("inactive", StringComparison.InvariantCultureIgnoreCase))
        active = false;
    currentCount = testBase.campaignRepository.GetCampaignsAsync(active).Result.Count();
}

Specflow Hook

[AfterScenario("rollback")]
public void AfterScenario()
{
    testBase.dbContextTransaction.Rollback();
}

Answer 2

Update

As your description, your test suite has already provided a good level of granularity, but when converting them to automated tests they get a number of dependencies (prepare data, object .. etc). My suggestion is that you can do the dependent steps directly in DB.

About the granularity, we just convert test case to automated test, so it will be the same level of granularity as what your test suite has provided.

Original Do you or your team have permission to access database ? If yes, you can prepare pre-condition data directly in database

• Write some store procedures to setup pre-condition step.
• Run these setup on Test account.
• Create a job to clean everything on Test account each day.