Cross-Browser Testing in TestNG

 Cross-Browser Testing in TestNG 

1. What Is Cross-Browser Testing?

Cross-Browser Testing is the process of verifying that a web application functions correctly and consistently across multiple web browsers (and often different browser versions or operating systems). Because each browser interprets HTML, CSS and JavaScript slightly differently, you may see layout glitches, JavaScript errors or API quirks if you only test in one environment.

2. Why Do We Need Cross-Browser Testing?

User Reach & Satisfaction: Your users may be on Chrome, Firefox, Edge, Safari or even legacy browsers—ensuring compatibility maximizes your audience.

Rendering Differences: CSS support, flexbox/grid behavior or font rendering can differ, causing layout breaks.

JavaScript & API Support: Some browsers lag on ES6 features, WebSockets, WebRTC, or fingerprinting APIs.

Browser Bugs: Occasionally a browser has its own quirks or bugs; early detection prevents production surprises.

Regulatory & Accessibility: Certain enterprises mandate support for specific, sometimes older, browsers.

3. Practical Example of Cross-Browser Testing

Imagine you have a login form that, in Chrome, submits and redirects correctly, but in Firefox the “Enter” key isn’t triggering the submit button because of event-handling differences. A cross-browser test would:

1. Navigate to your login page
2. Enter credentials
3. Submit via clicking the button and via the Enter key
4. Assert that the post-login dashboard loads

By running that same test against multiple browser drivers, you’ll catch the Firefox-specific issue before your users do.

4. How to Perform Cross-Browser Testing Using TestNG

The most common approach in TestNG + Selenium is to parameterize the browser value in your testng.xml, inject it via @Parameters, and initialize the corresponding WebDriver. You then run multiple <test> blocks, each with a different browser parameter.

4.1. testng.xml Configuration #

<!DOCTYPE suite SYSTEM “https://testng.org/testng-1.0.dtd”>

<suite name=”CrossBrowserSuite” parallel=”tests” thread-count=”2″>

  <!– Chrome tests –>

  <test name=”ChromeTests”>

    <parameter name=”browser” value=”chrome”/>

    <classes>

      <class name=”com.example.tests.CrossBrowserLoginTest”/>

    </classes>

  </test>

  <!– Firefox tests –>

  <test name=”FirefoxTests”>

    <parameter name=”browser” value=”firefox”/>

    <classes>

      <class name=”com.example.tests.CrossBrowserLoginTest”/>

    </classes>

  </test>

  <!– Edge tests –>

  <test name=”EdgeTests”>

    <parameter name=”browser” value=”edge”/>

    <classes>

      <class name=”com.example.tests.CrossBrowserLoginTest”/>

    </classes>

  </test>

</suite>

• parallel=”tests” + thread-count=”2″ runs two browser sessions concurrently.
• Each <test> block overrides the browser parameter for that run.

4.2. Selenium + TestNG Java Class #

package com.example.tests;

import org.testng.annotations.*;

import org.openqa.selenium.WebDriver;

import org.openqa.selenium.chrome.ChromeDriver;

import org.openqa.selenium.firefox.FirefoxDriver;

import org.openqa.selenium.edge.EdgeDriver;

import org.openqa.selenium.By;

public class CrossBrowserLoginTest {

    private WebDriver driver;

    @BeforeClass

    @Parameters(“browser”)

    public void setUp(@Optional(“chrome”) String browser) {

        switch (browser.toLowerCase()) {

            case “firefox”:

                System.setProperty(“webdriver.gecko.driver”, “/path/to/geckodriver”);

                driver = new FirefoxDriver();

                break;

            case “edge”:

                System.setProperty(“webdriver.edge.driver”, “/path/to/edgedriver”);

                driver = new EdgeDriver();

                break;

            default:

                System.setProperty(“webdriver.chrome.driver”, “/path/to/chromedriver”);

                driver = new ChromeDriver();

        }

        driver.manage().window().maximize();

    }

    @Test

    public void loginTest() {

        driver.get(“https://your-app.example.com/login”);

        // 1. Enter credentials

        driver.findElement(By.id(“username”)).sendKeys(“testuser”);

        driver.findElement(By.id(“password”)).sendKeys(“secret”);

        // 2a. Click the login button

        driver.findElement(By.id(“loginBtn”)).click();

        // 2b. Also ensure Enter key works

        // (optional: simulate KeyEvent and re-submit if needed)

        // 3. Verify post-login

        String title = driver.getTitle();

        Assert.assertTrue(title.contains(“Dashboard”), 

            “Login failed or dashboard title mismatch in ” + driver);

    }

    @AfterClass

    public void tearDown() {

        if (driver != null) {

            driver.quit();

        }

    }

}

• @Parameters(“browser”) injects the browser name from XML.
• The switch selects the appropriate driver binary.
• The same loginTest() runs unmodified across Chrome, Firefox and Edge.

4.3. Running the Suite #

• Command Line

mvn test -Dsurefire.suiteXmlFiles=testng.xml

• Eclipse / IntelliJ
  Right-click testng.xml → Run as TestNG Suite.

TestNG will spin up parallel sessions (per your thread-count) and execute the identical test logic in each browser, producing separate reports under test-output/.

4.4. Scaling Out #

• Selenium Grid: Point your WebDriver to a remote hub URL rather than local binaries to distribute across machines.
• BrowserStack / Sauce Labs: Use their RemoteWebDriver endpoints with desired capabilities for cloud testing on dozens of browser/OS combinations without local setup.
• Dynamic Parameters: Add more parameters (e.g. platform, version) to your XML and switch accordingly in setUp().

With this pattern you get a maintainable, data-driven way to ensure your web application behaves consistently across every browser your users may choose.