POM Framework Design with Global Elements

Question

New to C#, started learning in order to do test automation using Selenium C# with MS Visual Studio. Currently a manual tester.

I've been building a testing framework using TDD and the POM pattern. I'm still in the very early stages. I have about a dozen classes so far in 2 projects, the one project is dedicated to webdrivers with a single class called WebDriverFactory, the other project is broken into several folders where I have page classes, test classes, and a new folder I'm working on where there will be universal elements.

The application I'm automating has SO many elements which are on many different pages using the exact same selector and functioning in the exact same way. Also, there are many forms, selection boxes, inputs, etc., which use different locators, but behave in the exact same way - so I started to make a universal locators class and a universal methods class. The Locators class might be divided into several classes depending on arrangement on the pages or type of element. The Methods class will have methods which take the iwebelement locators and a variables to enter as arguments.

Here's an test method which currently runs and passes. I'm in the middle of refactoring it, using it as a guinea pig. As you can see, it uses a method from the Batches class to search for a provider, and then verifies that the correct provider is pulled using a method from the universal search methods class. Once I finish refactoring, it won't use the Batches class's method to search for a provider, but will also use a universal search class's method: because that style of search field is used a dozen times on each of a dozen pages for different search parameters... and there are several different styles of search fields as well...

 [TestMethod]
        [Description("Search by a single Provider and verify results match")]
        public void SingleProviderSearch()
        {
            var searchResultsActions = new SearchResultsActions(Driver);
            var searchResultsLocators = new SearchResultsLocators(Driver);

            var batches = new Batches(Driver);
            string provider = "Geisinger Medical Center";
            batches.GoTo();
            batches.EnterProvider(provider);
            batches.Search();
            //var batchesResults = new BatchesResults(Driver);
            //Assert.IsTrue(batchesResults.VerifyAllProvidersOfResults(provider), "The Provider column didn't match the searched-for Provider");
            Assert.IsTrue(searchResultsActions.VerifyTableColumn(provider, searchResultsLocators.ProviderColumn), "The Provider column didn't match the searched-for Provider");
            // Confirm Fails
            //Assert.IsTrue(batchesResults.VerifyAllProvidersOfResults("test"), "The Provider column didn't match the searched-for Provider");

How can I stick to the POM, when such a huge portion of the functionality is universal across the application? Don't get me wrong - there's unique stuff too.

One of the ideas I had was, which you see the beginnings of above, was to create a universal locators class which inherits from my base application class, then create a universal methods class which inherits from the universal locators class, then create the specific pages classes which inherit from the universal methods class.

Does that sound like a decent idea which will adhere to good design principles? It's the best compromise I've been able to come up with to balance DRY and POM.

So the question is: since I don't have programming experience, is the design pattern i've illustrated above, using a combination of POM but with a couple huge universal classes, feasible? Or is there another design pattern which would match the application better?

In order not to get this question closed - i'm not asking for opinions on that is the best, but simple practical ideas and solutions to overcome this design problem. Thanks!

Answer 1

What you are encountering is basically developers re-using components.

We are applying the same principle in our framework, so as to have only one extension method per type of component.

Some (pseudo) code to illustrate how we handle things:

Testmethod

PageX.EnterForm(data);
PageX.Save();

PageX page object class

public void EnterForm(data)
{
    // the variables below are simply WebElements initialize via PageFactory
    NameField.SetText(data);
    AddressField.SetText(data);
    PhoneField.SetText(data);
    BirthDateField.SetDate(data); // notice specific method for Date component
    StateField.SelectValue(data); // same for (custom) dropdowns
}

Framework method It's not really part of our Selenium framework, but rather a separate package consisting of extension methods on WebElement. You can think of it as directives. The code below is of course heavily abstracted, but if you have good framework methods you can do all kinds of things here with child elements, waiting, ...

If the component ever changes its behavior, you only need to update this method!

public void SetText(this IWebElement textbox, data)
{
    // Here you can have all kinds of logic used for all textboxes, for example:
    textbox.ShouldBeEditable();
    textbox.SendKeys();
    textbox.WaitForAutocomplete();
    textbox.ClickFirstResult();
    textbox.WaitForAutocompleteInvisible();
}

Answer 2

For this kind of situation where your developers are reusing components and/or there are a lot of common components in your application, you might want to consider using pattern objects instead of page objects.

You might have a pattern object of textField with a findBy property that lets you uniquely identify the field by doing something like

myTextField = textField.findBy("id", "Search");

It won't matter what page is involved - you use the normal methods to set search text and run the search, then you have a pattern object that you might call searchResults which could be a table that has specific headings and expected text if no results are found.

For more information there's a good article on TechBeacon covering the principle. (I have no affiliation: I read the article and was impressed)

Answer 3

I have been using a "Fluent POM" pattern as shown in my answer here.

App is a wrapper for the WebDriver. A Page class is a property in the app. And elements are properties in the Page. In addition to having properties they also have methods that pertain to that level. Like OpenUrl() is in the App class and FillOutForm() is in the login page class. I also add a lot of logging in my wrapper classes. I have one for NUnit's asserts, too.

class App {
    HomePage HomePage { return new HomePage(); }
}

class BasePage {
    IWebElement H1PageHeader { return new IWebElement(By.TagName("h1")); }
}

class HomePage : BasePage {
    HomePage HomePage(){ /* empty constructor */ }
    IWebElement MyElement { return new IWebElement(By.Id("foo")); }
}

class Test {
    [Test]
    Example01() {
        App.HomePage.H1PageHeader.WaitForElement();
        App.HomePage.MyElement.Click();
    }
}

Answer 4

Seems like you have acute case of Object Patterns Poisoning. :-)

You don't have much experience, so IMHO you should focus less on patterns and factories creating new classes, and more about parametrizable components. You should refactor your code only after you have 3-4-5 different use cases. Don't try to make your classes generic too soon. Such early generalization invites over-engineering. Composition is easier than inheritance, and inheritance is easier than factory pattern.

There are other design principles beyond DRY: KISS, YAGNI. If you want to read more about patterns and anti-patterns, you might want to look at the first original wiki: http://wiki.c2.com/ - still around. Also, you might consider looking around at https://softwareengineering.stackexchange.com/ - they have plenty of debates about system design.

Answer 5

Disclaimer: I am not an expert. I am still learning this craft.

Just like you I was also testing an application which had multiple functionality universal in nature. I also tried to implement POM + PageFactory but the framework was becoming too complex.

Instead of using @FindBy I store the locators as By Class object. I also changed few class and package structure to make my framework more.

1. Modular
2. Easy to Understand
3. Easy to Maintain

Below Framework is just for reference:

I divided the project mainly in 4 parts(package).

1. BaseFramework (Containing the GlobalVariables and Wrapper Class)
2. PageWise Class (in this example LoginPage)
3. Utilities (ex: YMLWrapper and ExcelWrapper used to Read and Write files)
4. Test Cases (containing the various test cases)

Folder Structure:

Hierarchy of the classes in the BaseFramework package is as below: So the BaseClass ends up having all the methods of the above inherited classes.

GlobalVariable Class holds variables like

• WebDriver driver;
• WebDriverWait wait; etc.

SeleniumWrapper Class holds methods like

• openBrowser(String browserName);
• click(By locator);
• enterText(By locator, String text); etc.

DatabaseWrapper Class holds methods to initial database connection.

• initDataBaseConnection(String databaseURL , String databaseUserName , String databasePassword)

BaseClass does not have any methods just acts as the class containing all the inherited methods in one place.

LoginPage Class code will look something like this.

public class LoginPage {

    By byUsernameTextBoxID = By.id("id_of_the_Username_Textbox");
    By byPasswordTextBoxID = By.id("id_of_the_Password_Textbox");
    By bySignInButtonName  = By.id("Name_of_the_Username_Textbox");
    
    BaseClass loginPageObject = new BaseClass();

    
    public void openBrowserAndLoginIntoWebsite() {
        //write the code to open Browser
        //write the code to Login into the application
    }
    
}

TestLoginFunctionality Class code will look something like this:

public class TestLoginFunctionality extends LoginPage {

        @Test
        public void testLoginFunctionality() {
            openBrowserAndLoginIntoWebsite();
            //Assert something on the page(ex: copyright statement, logo) 
        }
        
}

This is not the perfect framework but I hope it gives you some idea.

You can add more Wrapper to deal with REST API Testing, or Read and Write .XML, .properties files, etc.

Any kind of feedback is most welcomed. :-)