C-Pom_Dom-banner
NUnit Page Object Model (POM) & Data Object Model (DOM) Selenium with C#

Mastering Selenium C# with NUnit: In-Depth Guide to Page Object Model (POM) and Data Object Model (DOM)

by November 18, 2024

In this fast changing software development environment, application reliability and quality can only be ensured by efficient test automation solutions that scale well. Selenium is an open-source tool for automating browser interactions. It is very flexible in terms of usage because one may choose to use any language like C# along with it and thus has become much-needed for the automation framework. However, increased complexity in applications makes it difficult to maintain the robust framework of automation.           

Such complexities are addressed by the powerful use of design patterns like Page Object Model and Data Object Model, which prove extremely advantageous in organizing the test code for maximum efficiency without much redundancy. The Page Object Model is a design approach where it structures the test code so that test scripts are segregated from the application’s UI elements, encapsulating each page’s structure and behavior into dedicated classes. This allows QA teams to control page interactions by themselves, and tests become more readable, maintainable, and flexible with UI changes.

Data Object Model (DOM) is an extension of POM that separates test data from test logic for facilitating easy input management and testing usability of various scenarios. Its structure is suitable for huge projects where huge quantities of data are being handled and many variants are supported; it makes the testers easily reuse their test logic with various different sets of data.

We’ll show you how to implement POM and DOM using Selenium with C# from setup to best practices and concrete examples. Understanding these patterns will give you the power to design an automation framework that scales well across its needs when your tests are at once simple and robust.

🎯Understanding POM and DOM

What is the Page Object Model (POM)?

Page Object Model (POM) is a design pattern for test automation wherein a different class or “Page Object” is created for every web page in an application. Every page object can be considered as an abstraction layer that encapsulates the page’s structure or locators and the behavior of the page or methods or actions by which any user could perform on that specific page.

Key Features of POM:

  • Abstraction of UI Elements: Having elements and actions defined in separate classes maintains the cleanliness of test scripts, which are basically focused on test logic rather than low-level details about the structure of the page.
  • Modularity: A different class for each web page means testing for each web page can be done independently, especially when UI changes are perceived.
  • Code Reusability: Methods that interact with specific elements can be reused by several tests without duplication.
  • Read and Maintainability: Tests are much easier to read and maintain because the page structure is abstracted from the test’s logic. Changes in the UI have to be updated only in one place.

Example of a POM Class for a Login Page in C#:

using OpenQA.Selenium;

public class LoginPage
{
    private readonly IWebDriver driver;
    private readonly By usernameField = By.Id("username");
    private readonly By passwordField = By.Id("password");
    private readonly By loginButton = By.Id("login");

    public LoginPage(IWebDriver driver)
    {
        this.driver = driver;
    }

    public void EnterUsername(string username)
    {
        driver.FindElement(usernameField).SendKeys(username);
    }

    public void EnterPassword(string password)
    {
        driver.FindElement(passwordField).SendKeys(password);
    }

    public void ClickLoginButton()
    {
        driver.FindElement(loginButton).Click();
    }
}

In this example, the LoginPage class has specific methods to interact with the login page, making it easy to call EnterUsername, EnterPassword, and ClickLoginButton within test scripts without handling the low-level details of element locators.

What is the Data Object Model (DOM)?

Data Object Model (DOM) is a data interface with programming language-related technologies. Another design pattern for test automation is the Data Object Model. The test data here is separated from the logic for the test. It means that in DOM, test data will be stored in a structured format to enable data-driven tests. DOM enables testers to create versatile, reusable tests by storing inputs and expected outputs externally in files (e.g., JSON, CSV, XML, databases) rather than hardcoding them within test scripts.

Benefits of DOM:

  • Data-Driven Testing: DOM makes it easy to run tests with multiple data sets, supporting broader test coverage and scenario variation.
  • Simplifies Data Management: Test data is centralized and organized, making it easy to update or modify data without altering the test scripts.
  • Reusability and Scalability: DOM supports test reusability across different scenarios and environments, especially useful for applications with complex data inputs.

Example of Data-Driven Testing with NUnit and DOM in C#:

[Test, TestCaseSource("LoginData")]
public void TestLogin(string username, string password)
{
	var loginPage = new LoginPage(_driver);
	loginPage.EnterUsername(username);
	loginPage.EnterPassword(password);
	loginPage.ClickLoginButton();
	Assert.IsTrue(IsLoggedIn());
}
 
public static IEnumerable<TestCaseData> LoginData()
{
	yield return new TestCaseData("user1", "pass1");
	yield return new TestCaseData("user2", "pass2");
}

Here, LoginData provides different sets of usernames and passwords, allowing the test to validate the login functionality across multiple scenarios without changing the code in TestLogin.

Why POM and DOM are Essential for Test Automation

POM and DOM are absolutely necessary for the development of a robust, maintainable test automation framework. They offer modularity, scalability, and reusability for making the entire process of automated test development much more efficient and reliable. Here’s why each pattern is essential:

  • Modularity and Separation of Concerns: POM helps separate test scripts from the UI elements of the application. Similarly, DOM separates data from the test scripts. This separation reduces the impact of application changes on the test suite and centralizes changes.
  • Maintainability: Both POM and DOM reduce the need to modify multiple tests when UI or data changes occur. POM isolates changes within the page classes, while DOM centralizes data updates.
  • Reusability: POM allows testers to reuse page classes across different tests, while DOM enables the reuse of data across test scenarios. This reduces redundancy and speeds up the test creation process.
  • Enhanced Readability and Collaboration: By following these patterns, automation code is easier to read, update, and understand, making it accessible to both developers and testers. This also enables better collaboration and integration in agile environments.

Together, POM and DOM form the foundation of a scalable, maintainable test automation framework. By adopting these patterns, teams can build flexible test suites that adapt quickly to application changes and support a wide range of test scenarios.

Setting Up Your Environment

For setting up Selenium C#, you can refer to our Selenium C# blog, which covers everything from installation to configuration, ensuring you’re ready to start building robust automation tests in no time.

Creating a Page Object Model (POM) Structure

To effectively build and maintain automated tests, using a structured approach is key. The Page Object Model (POM) organizes your automation code by creating distinct classes for each web page. This separation ensures that changes to the user interface only need updates in one place, increasing reusability and maintainability.

Organizing and Creating Page Classes

In a POM structure, each page of the web application is represented by a separate class, known as a “page class.” These classes encapsulate the page’s elements and behaviors, making your tests modular, easier to read, and less error-prone.

  1. Create a Directory for Page Objects:
    • In your project structure, add a folder named Pages where you’ll store individual page classes.
  2. Define Page Classes for Each Web Page:
    • Each page class will contain locators for the elements on that page and methods for interactions (clicks, text inputs, selections, etc.).
    • Each page class includes:
      1. Locators for elements (defined by By objects).
      2. Methods for actions on the page (like filling in a form or clicking a button).

Using Page Factory for Element Initialization

Page Factory in Selenium is a tool to simplify the initialization of web elements. It helps avoid repetitive FindElement calls by letting you initialize elements with annotations.However, note that PageFactory is now deprecated in the latest Selenium versions, so for modern Selenium code, you might opt for direct FindElement calls in the page classes. Below, we’ll demonstrate both the PageFactory approach (for reference) and the recommended direct approach.

Example Page Class Using PageFactory (Deprecated Approach)

using OpenQA.Selenium;
using SeleniumExtras.PageObjects;

namespace SeleniumTestProject.Pages
{
    public class LoginPage
    {
        private readonly IWebDriver driver;

        [FindsBy(How = How.Id, Using = "username")]
        private IWebElement UsernameField;

        [FindsBy(How = How.Id, Using = "password")]
        private IWebElement PasswordField;

        [FindsBy(How = How.Id, Using = "login")]
        private IWebElement LoginButton;

        public LoginPage(IWebDriver driver)
        {
            this.driver = driver;  // Correct assignment of driver
            PageFactory.InitElements(driver, this);  // Initializes elements
        }

        public void EnterUsername(string username)
        {
            UsernameField.SendKeys(username);
        }

        public void EnterPassword(string password)
        {
            PasswordField.SendKeys(password);
        }

        public void ClickLoginButton()
        {
            LoginButton.Click();
        }
    }
}

This setup allows automatic initialization of elements using the FindsBy annotation. However, if you’re using a newer version of Selenium, you might want to skip PageFactory and initialize elements manually, as shown in the example below.

Recommended Page Class Without PageFactory

using OpenQA.Selenium;

namespace SeleniumTestProject.Pages
{
    public class LoginPage
    {
        private readonly IWebDriver driver;
        private By usernameField = By.Id("username");
        private By passwordField = By.Id("password");
        private By loginButton = By.Id("login");

        public LoginPage(IWebDriver driver)
        {
            this.driver = driver;
        }

        public void EnterUsername(string username)
        {
            driver.FindElement(usernameField).SendKeys(username);
        }

        public void EnterPassword(string password)
        {
            driver.FindElement(passwordField).SendKeys(password);
        }

        public void ClickLoginButton()
        {
            driver.FindElement(loginButton).Click();
        }
    }
}

With the Page Object Model:

  • Each page class represents a web page, encapsulating elements and actions.
  • Test scripts become clearer and more modular by calling specific page class methods.
  • Page factory was previously used for element initialization, but it is now recommended to manually locate elements in the latest Selenium versions.

This structure helps keep your test scripts clean, maintainable, and scalable, laying a solid foundation for implementing more complex test scenarios.

Implementing POM in a Real-World Scenario

In real-world applications, using POM effectively involves handling complex page interactions, managing dynamic elements, and navigating across multiple pages. Here, we’ll explore how to address these challenges, demonstrating with an example of setting up separate page classes for different sections of a website.

Handling Complex Page Interactions with POM

Complex interactions can involve multiple actions, conditional logic, or even handling various states of a web element. In POM, it’s best to encapsulate this logic within the page classes themselves to keep the test scripts simple.

For example, consider an e-commerce test. The ProductPage can include interactions such as the selection of a variant of a product (e.g., color or size), adding the item to the cart, verifying that the cart updates

Creating the ProductPage Class with Complex Interactions

using OpenQA.Selenium;

namespace SeleniumTestProject.Pages
{
    public class ProductPage
    {
        private readonly IWebDriver driver;

        private By productOptionDropdown = By.Id("product-options");
        private By addToCartButton = By.Id("add-to-cart");
        private By cartItemCount = By.Id("cart-count");

        public ProductPage(IWebDriver driver)
        {
            this.driver = driver;
        }

        // Method to select a product option from a dropdown
        public void SelectProductOption(string option)
        {
            var dropdown = driver.FindElement(productOptionDropdown);
            dropdown.Click();
            dropdown.FindElement(By.XPath($"//option[text()='{option}']")).Click();
        }

        // Method to add the product to the cart
        public void AddToCart()
        {
            driver.FindElement(addToCartButton).Click();
        }

        // Method to verify if item count in the cart is as expected
        public bool IsItemAddedToCart(int expectedCount)
        {
            string cartCountText = driver.FindElement(cartItemCount).Text;
            int cartCount = int.Parse(cartCountText);
            return cartCount == expectedCount;
        }
    }
}

In this example, the ProductPage class:

  • Encapsulates product selection logic by allowing the selection of specific options.
  • Handles conditional logic (e.g., verifying the cart item count after adding a product).
  • Keeps test cases concise by abstracting details into reusable methods.

Managing Dynamic Elements and Multi-Page Navigation

Dynamic elements are elements that change frequently, appear/disappear based on user actions, or load asynchronously. To manage them, you can use Selenium’s waiting mechanisms (like WebDriverWait) directly in your page classes.

For multi-page navigation, create separate page classes for each section and handle the transitions between pages in the test scripts or utility functions.

Example: Using Waits for Dynamic Elements on the CartPage

using OpenQA.Selenium;
using OpenQA.Selenium.Support.UI;
using System;

namespace SeleniumTestProject.Pages
{
    public class CartPage
    {
        private readonly IWebDriver driver;
        private WebDriverWait wait;

        private By checkoutButton = By.Id("checkout");
        private By cartTotal = By.Id("cart-total");

        public CartPage(IWebDriver driver)
        {
            this.driver = driver; // Properly assigning the driver instance
            this.wait = new WebDriverWait(driver, TimeSpan.FromSeconds(10)); // Properly initializing the wait
        }

        // Waits for the checkout button to be clickable
        public void ClickCheckout()
        {
            wait.Until(ExpectedConditions.ElementToBeClickable(checkoutButton)).Click();
        }

        // Gets the cart total after waiting for it to be visible
        public string GetCartTotal()
        {
            var cartTotalElement = wait.Until(ExpectedConditions.ElementIsVisible(cartTotal));
            return cartTotalElement.Text;
        }
    }
}

Here, the CartPage class uses WebDriverWait to:

  • Ensure elements like the Checkout button are clickable before interacting with them.
  • Retrieve values (e.g., cart total) only once they are fully loaded and visible.

Example: Implementing Multi-Page Navigation with Separate Page Classes

Let’s create separate classes for HomePage, ProductPage, and CartPage. In the test script, we can then interact with these classes to navigate through the flow.

HomePage Class

using OpenQA.Selenium;

namespace SeleniumTestProject.Pages
{
    public class HomePage
    {
        private IWebDriver driver;  // No underscore as per C# conventions for private fields

        private By searchBox = By.Id("search-box");
        private By searchButton = By.Id("search-button");

        public HomePage(IWebDriver driver)
        {
            this.driver = driver;  // Correct assignment of driver
        }

        public void SearchForProduct(string productName)
        {
            driver.FindElement(searchBox).SendKeys(productName);  // Corrected variable name
            driver.FindElement(searchButton).Click();  // Corrected variable name
        }

        // Navigates to a specific product's page based on search results
        public ProductPage SelectProductFromSearchResults(string productName)
        {
            var productLink = driver.FindElement(By.LinkText(productName));  // Corrected to use driver
            productLink.Click();
            return new ProductPage(driver); // Returns an instance of ProductPage
        }
    }
}

Example Test Class Using Multiple Pages

Now, in the test class, we’ll bring together HomePage, ProductPage, and CartPage classes to create a comprehensive test flow.

using NUnit.Framework;
using OpenQA.Selenium;
using OpenQA.Selenium.Chrome;
using SeleniumTestProject.Pages;

namespace SeleniumTestProject.Tests
{
    [TestFixture]
    public class ECommerceTests
    {
        private IWebDriver driver;
        private HomePage homePage;
        private ProductPage productPage;
        private CartPage cartPage;

        [SetUp]
        public void Setup()
        {
            driver = new ChromeDriver();  // Initialize the driver correctly
            driver.Navigate().GoToUrl("https://example-ecommerce.com");
            homePage = new HomePage(driver);  // Correctly initialize HomePage with driver
        }

        [Test]
        public void AddProductToCartTest()
        {
            // Search for a product
            homePage.SearchForProduct("Laptop");

            // Navigate to ProductPage and add product to the cart
            productPage = homePage.SelectProductFromSearchResults("Laptop");
            productPage.SelectProductOption("16GB RAM");
            productPage.AddToCart();

            // Navigate to CartPage and verify the cart total
            cartPage = new CartPage(driver);  // Initialize CartPage with driver
            cartPage.ClickCheckout();
            string cartTotal = cartPage.GetCartTotal();  // Use cartPage object correctly

            Assert.AreEqual("$1200", cartTotal, "Cart total did not match expected value.");
        }

        [TearDown]
        public void Teardown()
        {
            driver.Quit();  // Close the driver after tests are completed
        }
    }
}

In this test:

  • HomePage: Initiates a product search and selects a specific item from search results.
  • ProductPage: Configures the product options and adds the item to the cart.
  • CartPage: Proceeds to checkout and verifies the cart total.

Creating a Data-Driven Test Framework Using DOM

A Data-Driven Test Framework leverages test data to run tests with multiple inputs, allowing greater test coverage with minimal code duplication. When using Selenium with C#, you can combine NUnit and the Data Object Model (DOM) to create flexible, maintainable, and scalable tests. This section will focus on creating data-driven tests in NUnit and using DOM to pass test data to your Page Object Model (POM).

Writing Data-Driven Tests in NUnit

 NUnit is quite popular as a testing framework with C# and supports several data-driven testing approaches.Here are a few methods to feed data into your tests in NUnit:

  1. Using [TestCase] Attributes – Specifies individual data sets for a test method.
  2. Using [TestCaseSource] Attributes – Links to a data source like arrays, lists, or external files.
  3. Using CSV or JSON Files – Ideal for larger datasets.

Example: Writing a Data-Driven Test with [TestCase] Attributes

For basic data-driven testing, the [TestCase] attribute allows you to pass specific values directly into the test method. Let’s apply it to test login functionality.

using NUnit.Framework;
using OpenQA.Selenium;
using OpenQA.Selenium.Chrome;
using SeleniumTestProject.Pages;

namespace SeleniumTestProject.Tests
{
    [TestFixture]
    public class LoginTests
    {
        private IWebDriver driver;  // Removed underscore
        private LoginPage loginPage;  // Removed underscore

        [SetUp]
        public void Setup()
        {
            driver = new ChromeDriver();  // Correct initialization of driver
            driver.Navigate().GoToUrl("https://example.com/login");
            loginPage = new LoginPage(driver);  // Correct reference to loginPage
        }

        [Test]
        [TestCase("validUser", "validPassword", true)]
        [TestCase("invalidUser", "invalidPassword", false)]
        public void TestLogin(string username, string password, bool isSuccessExpected)
        {
            loginPage.EnterUsername(username);
            loginPage.EnterPassword(password);
            loginPage.ClickLoginButton();

            bool isSuccess = loginPage.IsLoginSuccessful();  // Correct usage of loginPage object
            Assert.AreEqual(isSuccessExpected, isSuccess, "Login success status did not match expected outcome.");
        }

        [TearDown]
        public void Teardown()
        {
            driver.Quit();  // Properly close the driver after the test
        }
    }
}

In this example:

  • [TestCase] Attributes: Define separate test cases with different sets of username/password combinations.
  • Parameter Passing: username, password, and isSuccessExpected are passed into the test method, allowing one method to handle multiple data sets.

Using External Data Sources with [TestCaseSource]

For larger or external data sets, [TestCaseSource] can be linked to a method or a file, such as a CSV or JSON file. Here, we’ll use a static method to provide test data.

using NUnit.Framework;
using OpenQA.Selenium;
using OpenQA.Selenium.Chrome;
using SeleniumTestProject.Pages;
using System.Collections;

namespace SeleniumTestProject.Tests
{
    [TestFixture]
    public class LoginTests
    {
        private IWebDriver driver;
        private LoginPage loginPage;

        [SetUp]
        public void Setup()
        {
            driver = new ChromeDriver();
            driver.Navigate().GoToUrl("https://example.com/login");
            loginPage = new LoginPage(driver);
        }

        private static IEnumerable TestData()
        {
            // Example test cases
            yield return new TestCaseData("validUser", "validPassword").Returns(true);
            yield return new TestCaseData("invalidUser", "invalidPassword").Returns(false);
        }

        [Test, TestCaseSource(nameof(TestData))]
        public bool TestLoginWithExternalData(string username, string password)
        {
            // Login logic here
            loginPage.EnterUsername(username);
            loginPage.EnterPassword(password);
            loginPage.ClickLoginButton();

            return loginPage.IsLoginSuccessful(); // Correct reference to loginPage
        }

        [TearDown]
        public void Teardown()
        {
            driver.Quit();
        }
    }
}

Passing Test Data to POM Using DOM

With the Data Object Model (DOM), you separate test data from test logic by defining data sources (like files or objects) that feed values to the page objects during test execution. This separation helps manage and update test data easily, enhancing test reusability.

Let’s create a TestData class and use it as a centralized location for our test data. In real-world scenarios, this could be further expanded to pull data from external sources like JSON or databases.

Example: Creating a TestData Class for Login Details

namespace SeleniumTestProject.Data
{
    public static class TestData
    {
        public static string ValidUsername => "validUser";
        public static string ValidPassword => "validPassword";
        public static string InvalidUsername => "invalidUser";
        public static string InvalidPassword => "invalidPassword";
    }
}

In this example, TestData is a static class that stores reusable test data. This class can be expanded or replaced by an external data source as needed.

Passing DOM Test Data to POM

In the login test, you can now pull in data from TestData instead of hard-coding it in the test cases.

using NUnit.Framework;
using OpenQA.Selenium;
using OpenQA.Selenium.Chrome;
using SeleniumTestProject.Pages;
using SeleniumTestProject.Data;

namespace SeleniumTestProject.Tests
{
    [TestFixture]
    public class LoginTests
    {
        private IWebDriver driver; // Use driver without underscore to match your naming conventions
        private LoginPage loginPage;

        [SetUp]
        public void Setup()
        {
            driver = new ChromeDriver();
            driver.Navigate().GoToUrl("https://example.com/login");
            loginPage = new LoginPage(driver); // Correctly reference the driver
        }

        [Test]
        public void TestValidLogin()
        {
            loginPage.EnterUsername(TestData.ValidUsername);
            loginPage.EnterPassword(TestData.ValidPassword);
            loginPage.ClickLoginButton();
            Assert.IsTrue(loginPage.IsLoginSuccessful(), "Valid login failed.");
        }

        [Test]
        public void TestInvalidLogin()
        {
            loginPage.EnterUsername(TestData.InvalidUsername);
            loginPage.EnterPassword(TestData.InvalidPassword);
            loginPage.ClickLoginButton();

            Assert.IsFalse(loginPage.IsLoginSuccessful(), "Invalid login succeeded.");
        }

        [TearDown]
        public void Teardown()
        {
            driver.Quit();
        }
    }
}

Using JSON Data Files with DOM

For more dynamic data, consider using JSON files to store your test data, especially for complex data sets.

Sample JSON File (LoginData.json)

json
{
  "validLogin": {
	"username": "validUser",
	"password": "validPassword"
  },
  "invalidLogin": {
	"username": "invalidUser",
	"password": "invalidPassword"
  }
}

Loading JSON Data in C#

You can load this JSON data into a C# object using Newtonsoft.Json (a popular library for JSON handling).

using System.IO;
using Newtonsoft.Json;
 
namespace SeleniumTestProject.Data
{
	public class LoginData
	{
    	public string Username { get; set; }
    	public string Password { get; set; }
 
    	public static LoginData LoadFromJson(string key)
    	{
        	var data = JsonConvert.DeserializeObject<Dictionary<string, LoginData>>(
                File.ReadAllText("path/to/LoginData.json"));
        	return data[key];
    	}
    }
}

Using JSON Data in Tests

using NUnit.Framework;
using OpenQA.Selenium;
using OpenQA.Selenium.Chrome;
using SeleniumTestProject.Pages;
using SeleniumTestProject.Data;

namespace SeleniumTestProject.Tests
{
    [TestFixture]
    public class LoginTests
    {
        private IWebDriver driver;
        private LoginPage loginPage;

        [SetUp]
        public void Setup()
        {
            driver = new ChromeDriver();
            driver.Navigate().GoToUrl("https://example.com/login");
            loginPage = new LoginPage(driver);
        }

        [Test]
        public void TestValidLoginWithJsonData()
        {
            var loginData = LoginData.LoadFromJson("validLogin");

            loginPage.EnterUsername(loginData.Username);
            loginPage.EnterPassword(loginData.Password);
            loginPage.ClickLoginButton();

            Assert.IsTrue(loginPage.IsLoginSuccessful(), "Valid login failed.");
        }

        [Test]
        public void TestInvalidLoginWithJsonData()
        {
            var loginData = LoginData.LoadFromJson("invalidLogin");

            loginPage.EnterUsername(loginData.Username);
            loginPage.EnterPassword(loginData.Password);
            loginPage.ClickLoginButton();

            Assert.IsFalse(loginPage.IsLoginSuccessful(), "Invalid login succeeded.");
        }

        [TearDown]
        public void Teardown()
        {
            driver.Quit();
        }
    }
}

In this section, we covered:

  • Data-driven testing in NUnit with [TestCase] and [TestCaseSource] attributes.
  • Using DOM to pass test data from centralized classes or external files to the POM classes.
  • External JSON files for large, organized, and reusable test data sets.

This approach enhances reusability and makes your tests more manageable, especially when dealing with large datasets or complex testing scenarios.

Advanced Topics in POM and DOM

As your Selenium framework grows, it’s essential to focus on best practices and advanced techniques to keep the code clean, manageable, and efficient. This section dives into implementing the DRY (Don’t Repeat Yourself) principle in Page Object Models (POM), managing AJAX calls and handling waiting mechanisms to enhance the reliability of your tests.

Implementing the DRY Principle in Page Objects

The DRY principle encourages minimizing code duplication by creating reusable methods and structures. Applying this principle to your Page Object Models can make them more maintainable and scalable.

Creating Base Page Classes

One way to reduce redundancy is by creating a BasePage class. This class can contain common methods or elements shared across multiple pages, such as handling navigation, waiting, and interacting with common components (e.g., headers or footers).

Here’s an example of a BasePage class:

using OpenQA.Selenium;
using OpenQA.Selenium.Support.UI;
using System;

namespace SeleniumTestProject.Pages
{
    public abstract class BasePage
    {
        protected IWebDriver Driver;
        protected WebDriverWait Wait;

        protected BasePage(IWebDriver driver)
        {
            Driver = driver;
            Wait = new WebDriverWait(Driver, TimeSpan.FromSeconds(10));  // Correctly passing Driver
        }

        protected IWebElement WaitForElementToBeVisible(By locator)
        {
            return Wait.Until(SeleniumExtras.WaitHelpers.ExpectedConditions.ElementIsVisible(locator));
        }

        protected void ClickElement(By locator)
        {
            WaitForElementToBeVisible(locator).Click();
        }

        protected void EnterText(By locator, string text)
        {
            WaitForElementToBeVisible(locator).SendKeys(text);
        }
    }
}

In this BasePage class:

  • WaitForElementToBeVisible, ClickElement, and EnterText are reusable methods that reduce the need to repeat these actions across multiple page objects.
  • The constructor initializes the WebDriver and WebDriverWait instances.

Extending BasePage in Other Page Classes

Your specific page classes, like LoginPage or HomePage, can inherit from BasePage, allowing them to use the common methods defined there. Here’s how this looks:

namespace SeleniumTestProject.Pages
{
    public class LoginPage : BasePage
    {
        private readonly By usernameField = By.Id("username");
        private readonly By passwordField = By.Id("password");
        private readonly By loginButton = By.Id("login");

        public LoginPage(IWebDriver driver) : base(driver) { }

        public void EnterUsername(string username)
        {
            EnterText(usernameField, username);
        }

        public void EnterPassword(string password)
        {
            EnterText(passwordField, password);
        }

        public void ClickLoginButton()
        {
            ClickElement(loginButton);
        }
    }
}

By extending BasePage, LoginPage can use methods like EnterText and ClickElement without having to redefine them. This not only keeps the code DRY but also makes maintenance easier.

Consolidating Repeated Actions

If your tests often repeat the same operations (such as login), you might consider introducing a utility or helper class to reuse throughout your tests.

Handling AJAX Calls and Waiting Mechanisms

AJAX calls are asynchronous and can introduce timing issues if elements load dynamically. Selenium provides several wait mechanisms to help synchronize tests with dynamic content.

Practical Example: Applying DRY and Advanced Waiting in a Login Flow

public class LoginPage : BasePage
{
    private readonly By usernameField = By.Id("username");
    private readonly By passwordField = By.Id("password");
    private readonly By loginButton = By.Id("login");

    public LoginPage(IWebDriver driver) : base(driver) { }

    public void Login(string username, string password)
    {
        EnterText(usernameField, username);
        EnterText(passwordField, password);
        ClickElement(loginButton);
    }

    public bool IsLoginSuccessful()
    {
        var dashboardLocator = By.Id("dashboard");
        return WaitForElementToBeVisible(dashboardLocator) != null;
    }
}

In this LoginPage:

  • DRY Principle: The Login method consolidates the login steps, making the test code shorter and more readable.
  • Waiting Mechanism: IsLoginSuccessful waits for the presence of a dashboard element before asserting login success, addressing potential timing issues from AJAX or dynamic loading.

In this section, we explored advanced topics essential for building scalable and reliable Selenium frameworks:

  • DRY Principle in POM – Using base classes and reusable methods to minimize redundancy.
  • AJAX Handling and Waiting Mechanisms – Leveraging explicit and fluent waits to handle asynchronous content dynamically.

By adhering to the DRY principle and implementing effective waiting mechanisms, you can make your Selenium tests more robust, maintainable, and efficient. This approach enables you to tackle real-world complexities in web automation confidently.

Common Pitfalls and How to Avoid Them

 In building robust test automation frameworks with Selenium, knowledge of common pitfalls is centrally important to the ability to create efficiency and scale. Below are some common issues testers face with the Page Object Model (POM) and Data Object Model (DOM), along with best practices for managing dependencies and troubleshooting.

Avoiding Over-Reliance on POM for Simple Tests

The Page Object Model is highly effective for creating structured, reusable code in large-scale test automation. However, using POM for every test case, particularly very simple ones, can add unnecessary complexity.

  • Avoiding Over-Reliance on POM for Simple Tests : The Page Object Model is highly effective for creating structured, reusable code in large-scale test automation. However, using POM for every test case, particularly very simple ones, can add unnecessary complexity.
  • When to Use POM : POM is ideal for tests involving complex interactions across multiple pages or applications with high UI changes. These test cases benefit from the modularity and maintainability that POM provides.
  • When POM May Be Overkill : For simple tests that involve minimal interaction (e.g., checking a page title or verifying a single element), creating a full-fledged page object may be unnecessary. Directly accessing elements and performing assertions within the test case itself can make these tests shorter, clearer, and faster.
  • Solution: Hybrid Approach : Use a hybrid approach by creating a few lightweight helper methods for simple interactions, rather than full POM structures. This can balance test simplicity with the maintainability benefits of POM.

Managing Dependencies Between POM and DOM

POM and DOM serve different purposes in test automation but can sometimes have dependencies that are challenging to manage. Ensuring loose coupling between them is essential for framework flexibility and ease of maintenance.

Best Practices for Reducing Tight Coupling

  • Separate Data Management: Keep test data management in separate data files or classes. Use JSON, XML, or a database as data sources and pass data to POM as parameters.
  • Use Interfaces: Implement interfaces for your page objects when you have multiple layers interacting with your pages. Interfaces add a layer of abstraction that reduces direct dependencies between test logic and page object implementations.

Example: Injecting Data with DOM in POM

Rather than hardcoding data in the page object, pass data from the DOM (data object) to the page object as parameters. This approach makes tests more flexible and easier to maintain.

public class LoginData
{
	public string Username { get; set; }
	public string Password { get; set; }
}
 
// In the test method
LoginPage loginPage = new LoginPage(driver);
LoginData loginData = new LoginData { Username = "user1", Password = "pass123" };
loginPage.Login(loginData);

In this example:

  • LoginData provides test data in a separate class, which can be serialized from JSON or another data source.
  • loginPage.Login(loginData) passes data to the page object, keeping data management separate from page interactions.

Troubleshooting Issues in Selenium with C#

When working with Selenium, especially in C#, you may encounter issues related to element handling, timing, or even test framework setup. Here are some troubleshooting tips for common problems:

Common Issue: Element Not Interactable Exception

This often occurs when the element is either not yet visible or another element obscures it The following are ways to deal with it:
Solution Use Explicit Waits The element should be fully loaded, and then visible before you start any interaction.

WebDriverWait wait = new WebDriverWait(driver, TimeSpan.FromSeconds(10));
IWebElement element = wait.Until(ExpectedConditions.ElementToBeClickable(By.Id("elementID")));
element.Click();

Alternate Solution: Scroll into View: If an element is off-screen scroll to it using JavaScript.

IJavaScriptExecutor js = (IJavaScriptExecutor)driver;
js.ExecuteScript("arguments[0].scrollIntoView(true);", element);
element.Click();

Common Issue: Stale Element Reference Exception

This error occurs when the DOM changes between finding an element and performing an action on it.

  • Solution: Refetch Elements: Refetch the element each time before interacting with it.
  • Alternative Solution: Wrap interactions in retry logic with a short delay when the element goes stale
for (int attempt = 0; attempt < 3; attempt++)
{
    try
    {
        IWebElement element = driver.FindElement(By.Id("dynamicElement"));
        element.Click();
        break;
    }
    catch (StaleElementReferenceException)
    {
        Thread.Sleep(500);
    }
}

Common Issue: Timeout on Dynamic Elements

For AJAX-driven applications, dynamic elements often take time to load, leading to test failures.

  • Solution: Fluent Waits: Use fluent waits with custom polling intervals to check for element visibility over time.
WebDriverWait wait = new WebDriverWait(driver, TimeSpan.FromSeconds(20))
{
	PollingInterval = TimeSpan.FromMilliseconds(500),
    IgnoreExceptionTypes(typeof(NoSuchElementException))
};
IWebElement dynamicElement = wait.Until(ExpectedConditions.ElementIsVisible(By.Id("ajaxElement")));
  • Alternative Solution: Implement Retry Mechanism for AJAX Calls: Retry AJAX checks periodically to wait for data to load.

Common Issue: Test Execution Slowing Down Over Time

This issue often occurs when the WebDriver instance accumulates overhead due to large test suites, causing gradual slowdowns.

  • Solution: Optimize Test Structure: Split large test suites and group tests logically to reduce overhead.
  • Solution: WebDriver Cleanup: Ensure proper cleanup and disposal of WebDriver instances between tests, particularly if you’re running multiple tests sequentially.
[TearDown]
public void TearDown()
{
	if (driver != null)
	{
    	driver.Quit();
	}
}

Common Issue: Compatibility and Version Issues

Sometimes tests fail because of version incompatibilities between Selenium WebDriver, browser drivers, or browser versions.

  • Solution: Regularly Update Dependencies: Keep WebDriver, browser drivers, and Selenium libraries updated to the latest compatible versions.
  • Solution: Use a Dependency Manager: Tools like NuGet for C# can help manage versioning and simplify updates.

Best practices in POM and DOM make one alert to common pitfalls or the way to avoid them while building a robust test automation framework. Here is a recap of the main points:

  • Avoid Over-Reliance on POM for Simple Tests: Reserve POM for complex interactions to prevent over-engineering.
  • Manage Dependencies Between POM and DOM: Use data injection and abstraction techniques to keep POM and DOM loosely coupled.
  • Troubleshooting Techniques: Implement reliable wait strategies, retry logic, and regular dependency updates to tackle common Selenium issues.

 Building a Sample Selenium Project with POM and DOM

Building a well-structured Selenium project with POM and DOM is the surest way of ensuring that your automation framework is scalable, maintainable, and efficient. In the article below, we will go through a step-by-step guide about setting up a sample Selenium project and providing an example project layout incorporating POM and DOM principles

Set Up a Folder Structure for the Project

To maintain clarity and scalability in the project, we will organize the code into several folders:

  • Pages: Where the Page Object classes will reside.
  • Data: For the DOM classes and test data management.
  • Tests: Where the test scripts will be written.
  • Utilities: To store reusable code such as WebDriver initialization, wait logic, etc.

Developing Classes for Page Object Model (POM)

 LoginPage.cs:

 The LoginPage.cs class will encompass the login page and accordingly, methods that do some action on the login page, such as entering a username and password and clicking the log in button.

using OpenQA.Selenium;
using SeleniumExtras.PageObjects;

public class LoginPage
{
    private IWebDriver driver;

    public LoginPage(IWebDriver driver)
    {
        this.driver = driver;
        PageFactory.InitElements(driver, this);
    }

    // Locate the web elements
    [FindsBy(How = How.Id, Using = "username")]
    private IWebElement usernameField;

    [FindsBy(How = How.Id, Using = "password")]
    private IWebElement passwordField;

    [FindsBy(How = How.Id, Using = "loginBtn")]
    private IWebElement loginButton;

    // Action methods
    public void EnterUsername(string username)
    {
        usernameField.SendKeys(username);
    }

    public void EnterPassword(string password)
    {
        passwordField.SendKeys(password);
    }

    public void ClickLogin()
    {
        loginButton.Click();
    }

    public HomePage Login(string username, string password)
    {
        EnterUsername(username);
        EnterPassword(password);
        ClickLogin();
        return new HomePage(driver);  // Return the HomePage object after login
    }
}

HomePage.cs:

The HomePage.cs class will represent the homepage that the user lands on after a successful login.

using OpenQA.Selenium;
using SeleniumExtras.PageObjects;

public class HomePage
{
    private IWebDriver driver;

    public HomePage(IWebDriver driver)
    {
        this.driver = driver;
        PageFactory.InitElements(driver, this);
    }

    [FindsBy(How = How.Id, Using = "logoutBtn")]
    private IWebElement logoutButton;

    public void ClickLogout()
    {
        logoutButton.Click();
    }
}

Create Data Object Model (DOM)

In this section, we’ll create a class that holds the login data, which can be passed to the POM to use in tests.

LoginData.cs:

public class LoginData
{
	public string Username { get; set; }
	public string Password { get; set; }
}

Write Test Cases

LoginTests.cs:

This file will contain the test logic. Below we will use LoginPage and HomePage objects to test the functionality of logging in.

using NUnit.Framework;
using OpenQA.Selenium;
using OpenQA.Selenium.Chrome;

[TestFixture]
public class LoginTests
{
    private IWebDriver driver;

    [SetUp]
    public void Setup()
    {
        driver = new ChromeDriver();
        driver.Manage().Window.Maximize();
    }

    [Test]
    public void TestLogin()
    {
        LoginPage loginPage = new LoginPage(driver);
        driver.Navigate().GoToUrl("https://example.com/login");

        LoginData loginData = new LoginData
        {
            Username = "testuser",
            Password = "testpassword"
        };

        HomePage homePage = loginPage.Login(loginData.Username, loginData.Password);

        // Assert that we are on the homepage after login
        Assert.IsTrue(homePage.IsLogoutButtonVisible());
    }

    [TearDown]
    public void TearDown()
    {
        driver.Quit();
    }
}

In this test:

  • We initialize the LoginPage object and pass the test data (via the LoginData object) to perform the login action.
  • After a successful login, we verify if we are redirected to the homepage by checking the visibility of the logout button.

WebDriverUtility.cs Example

WebDriverUtility.cs provides reusable code for WebDriver setup:

using OpenQA.Selenium;
using OpenQA.Selenium.Chrome;

public class WebDriverUtility
{
    public static IWebDriver GetDriver()
    {
        ChromeOptions options = new ChromeOptions();
        options.AddArgument("headless");  // Run the browser in headless mode for CI environments
        IWebDriver driver = new ChromeDriver(options);
        driver.Manage().Window.Maximize();
        return driver;
    }
}

This utility class helps in creating the WebDriver instance. It encapsulates the browser setup logic, and can be reused across different test classes.

Conclusion

In conclusion, the Page Object Model (POM) and Data Object Model (DOM) are foundational strategies for building effective, maintainable test automation frameworks with Selenium and C#. By using POM, testers can create structured and reusable page classes that encapsulate all interactions with web elements, making tests more readable and resilient to changes in the UI. Integrating DOM alongside POM takes this a step further by organizing and managing test data separately, supporting data-driven testing and enhancing flexibility across test scenarios.

When combined, POM and DOM provide a powerful framework that promotes the DRY (Don’t Repeat Yourself) principle, simplifies handling of dynamic elements, and streamlines complex multi-page interactions. Together, they create a modular, organized structure that is scalable and easy to maintain, even as projects grow in complexity. Implementing these models allows QA teams to build tests that are not only reliable but also adaptable, future-proofing automation efforts and paving the way for consistent, high-quality testing in Selenium C#.

Witness how our meticulous approach and cutting-edge solutions elevated quality and performance to new heights. Begin your journey into the world of software testing excellence. To know more refer to Tools & Technologies & QA Services.

If you would like to learn more about the awesome services we provide, be sure to reach out.

Happy testing! 🙂

Tags: