TestNG XML Generator for Parallel & Cross-Browser Suites

Why hand-written testng.xml files break

The TestNG DTD is strict about element order: inside a <test> block, <parameter> comes before <groups>, which comes before <classes> or <packages> — get it wrong and IntelliJ flags the file or the run silently ignores your filters. Add the confusion between thread-count and data-provider-thread-count, the missing DOCTYPE that disables IDE validation, and browser parameters placed at suite level (where they can never run browsers in parallel), and most hand-written suite files carry at least one of these defects. This generator encodes the correct structure so the file you download is the file you would write after reading the TestNG documentation end to end.

What it generates

• Parallel execution — parallel="methods|classes|tests|instances" with a matching thread-count, plus optional data-provider-thread-count, verbose, time-out and preserve-order.
• Cross-browser blocks — one <test> per browser (Chrome, Firefox, Edge, Safari) with a <parameter name="browser"> each, the pattern that actually parallelises browsers.
• Group filtering — <include> and <exclude> under <groups><run> for smoke, regression, sanity or any custom group.
• Fine-grained targeting — classes, whole packages, or single methods via <methods><include>.
• Listeners & parameters — <listeners> for reporters/retry analyzers and suite-level <parameter> entries for baseUrl, env or a Grid hubUrl.
• Valid XML, always — DOCTYPE header, DTD-ordered elements and escaped attribute values.

TestNG parallel modes at a glance

The cross-browser pattern that actually runs in parallel

A single suite-level browser parameter can only ever start one browser. The pattern that works is parallel="tests" with one <test> block per browser, each carrying its own parameter — exactly what the Cross-Browser preset produces:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE suite SYSTEM "https://testng.org/testng-1.0.dtd">
<suite name="Cross Browser Suite" parallel="tests" thread-count="3">
  <test name="Chrome Tests">
    <parameter name="browser" value="chrome"/>
    <classes>
      <class name="com.example.tests.LoginTest"/>
    </classes>
  </test>
  <test name="Firefox Tests">
    <parameter name="browser" value="firefox"/>
    <classes>
      <class name="com.example.tests.LoginTest"/>
    </classes>
  </test>
  <test name="Edge Tests">
    <parameter name="browser" value="edge"/>
    <classes>
      <class name="com.example.tests.LoginTest"/>
    </classes>
  </test>
</suite>

Reading the browser parameter in your test code

Pair the generated XML with a base class that turns the parameter into a driver. @Optional keeps the class runnable outside the suite file, and alwaysRun = true makes setup fire even when group filters are active:

public class CrossBrowserBase {
  protected WebDriver driver;

  @BeforeMethod(alwaysRun = true)
  @Parameters("browser")
  public void setUp(@Optional("chrome") String browser) {
    driver = DriverFactory.create(browser); // chrome, firefox, edge, safari
  }

  @AfterMethod(alwaysRun = true)
  public void tearDown() {
    if (driver != null) driver.quit();
  }
}

If you are building the framework around this file, our REST Assured + TestNG framework write-up covers the thread-safety decisions — immutable specs and ThreadLocal reporting — that make parallel="methods" boring in a good way.

How to use it

1. Pick a preset (Cross-Browser, Smoke, Regression, Parallel Methods or Selenium Grid) or configure from scratch.
2. Adjust the parallel mode, thread count, browsers, groups and classes — the preview updates as you type.
3. Click Copy or Download to get testng.xml.
4. Put it next to pom.xml, wire it into Maven Surefire (snippet included) or right-click-run it in your IDE.

Frequently asked questions