How to Run TestNG Using the Command Prompt

You run TestNG from the command prompt by compiling your test classes with the TestNG jar on the classpath, then executing the org.testng.TestNG class against a testng.xml suite file. On Windows the command is java -cp "bin;libs/*" org.testng.TestNG testng.xml; on Linux or macOS you swap the semicolon for a colon (bin:libs/*). If your project already uses Maven, the simplest route is a single mvn test, which reads the suite from your pom.xml and runs it for you.

Below we walk through the prerequisites and three reliable ways to launch TestNG from a terminal, explain the structure of testng.xml, troubleshoot the errors testers hit most often, and show how to scale the same suite across real browsers with automation testing.

Prerequisites

TestNG is a Java testing framework, so the only hard requirement is a working Java toolchain plus the framework jars. Before you open a terminal, make sure you have the following in place:

• A JDK (8 or newer) — you need javac to compile and java to run. Confirm with java -version and javac -version; both should print without an error.
• The TestNG jar — download testng.jar (and its companion jcommander.jar) from Maven Central, or let a build tool fetch them. Keep them together in a folder such as libs.
• Compiled test classes — your @Test classes compiled to .class files. IntelliJ writes these to an out folder and Eclipse to a bin folder.
• Optional: Maven — if you prefer build-tool execution, install Maven and verify it with mvn -version. Maven removes the need to assemble the classpath by hand.

A typical project layout looks like this: source files under src, compiled output under bin, third-party jars under libs, and a testng.xml at the project root. With that structure ready, compilation is a single command:

# Windows (note the semicolon classpath separator)
javac -cp "libs/*" -d bin src/com/example/*.java

# Linux / macOS (note the colon classpath separator)
javac -cp "libs/*" -d bin src/com/example/*.java

Method 1 - Run via testng.xml From the Command Line

This is the recommended approach because the XML suite is the single source of truth for which classes, methods, and groups run — the same file works locally, in CI, and on a cloud grid. TestNG ships a command-line runner, the org.testng.TestNG class, that takes one or more suite files as arguments.

Put the compiled classes folder (bin) and every framework jar (libs/*) on the classpath, then point the runner at testng.xml:

# Windows — classpath entries separated by a SEMICOLON ;
java -cp "bin;libs/*" org.testng.TestNG testng.xml

# Linux / macOS — classpath entries separated by a COLON :
java -cp "bin:libs/*" org.testng.TestNG testng.xml

When you press Enter, the JVM loads org.testng.TestNG, which reads your suite file, resolves the listed classes from the bin folder, and executes every @Test method according to the suite's configuration. Results are written to a test-output folder containing an index.html report and JUnit-style XML you can feed into a CI dashboard.

The libs/* wildcard is important: it expands to every jar in the folder, so testng.jar and jcommander.jar are both included. Listing only libs/testng.jar is the single most common cause of a missing-dependency error, covered in the troubleshooting section.

Two variations of this command are worth knowing. If the classpath is long or reused, set it once as an environment variable so the run command stays short. And because org.testng.TestNG accepts more than one suite file, you can run several suites in a single invocation by listing them one after another:

# Option A: set the classpath first, then keep the run command short (Windows)
set classpath=bin;libs/*
java org.testng.TestNG testng.xml

# Option B: run MULTIPLE suite files in one command
java -cp "bin;libs/*" org.testng.TestNG smoke.xml regression.xml

TestNG merges the listed suites into a single run and produces one combined report — useful when you keep separate smoke and regression suite files but want to execute them together in CI.

Method 2 - Run a Specific Test Class Without XML

For a quick smoke check you do not always need a suite file. The same org.testng.TestNG runner accepts flags that target individual classes, methods, or groups directly from the terminal — handy when you just want to rerun one failing test.

# Run one fully qualified test class (Windows)
java -cp "bin;libs/*" org.testng.TestNG -testclass com.example.LoginTest

# Run several classes at once
java -cp "bin;libs/*" org.testng.TestNG -testclass com.example.LoginTest com.example.CheckoutTest

# Run only tests tagged with a group
java -cp "bin;libs/*" org.testng.TestNG -groups smoke -testclass com.example.LoginTest

Use a colon instead of the semicolon on Linux or macOS (bin:libs/*). The -testclass flag is great for iteration speed, but for a repeatable, version-controlled suite definition you should still keep a testng.xml, because it documents the exact test scope for the whole team.

Method 3 - Run With Maven (mvn test)

If your project is a Maven project, you never assemble the classpath yourself — Maven resolves the TestNG dependency and runs the suite through the Surefire plugin. Declare TestNG as a dependency and tell Surefire which suite file to use:

<dependencies>
  <dependency>
    <groupId>org.testng</groupId>
    <artifactId>testng</artifactId>
    <version>7.10.2</version>
    <scope>test</scope>
  </dependency>
</dependencies>

<build>
  <plugins>
    <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-surefire-plugin</artifactId>
      <version>3.2.5</version>
      <configuration>
        <suiteXmlFiles>
          <suiteXmlFile>testng.xml</suiteXmlFile>
        </suiteXmlFiles>
      </configuration>
    </plugin>
  </plugins>
</build>

With that in place, running the whole suite is a single command from the project root:

# Compiles, resolves dependencies, and runs testng.xml
mvn test

# Run a single class without touching testng.xml
mvn test -Dtest=LoginTest

Maven is the friendliest option for CI pipelines because the classpath, separators, and dependency downloads are all handled for you, eliminating the platform-specific ; versus : headaches entirely.

The Structure of testng.xml

The suite file is plain XML with a clear hierarchy: a <suite> contains one or more <test> blocks, each of which lists the <classes> to run. You can also filter by <groups> and control parallel execution from the suite tag. Here is a minimal but complete example:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE suite SYSTEM "https://testng.org/testng-1.0.dtd">
<suite name="RegressionSuite" parallel="classes" thread-count="2">
  <test name="LoginTests">
    <classes>
      <class name="com.example.LoginTest"/>
      <class name="com.example.LogoutTest"/>
    </classes>
  </test>

  <test name="CheckoutTests">
    <groups>
      <run>
        <include name="smoke"/>
      </run>
    </groups>
    <classes>
      <class name="com.example.CheckoutTest"/>
    </classes>
  </test>
</suite>

The parallel and thread-count attributes let TestNG run tests concurrently, which is exactly what you want when scaling across many browsers. The <groups> block runs only the methods tagged smoke, so one suite file can serve both quick smoke runs and full regression by toggling includes.

Common Mistakes and Troubleshooting

• ClassNotFoundException: org.testng.TestNG — the TestNG jar is not on the classpath. Make sure -cp includes the folder or jar, and use the libs/* wildcard so no jar is missed.
• Wrong classpath separator — Windows uses a semicolon (bin;libs/*) and Linux/macOS use a colon (bin:libs/*). Use the wrong one and the JVM silently treats the whole string as a single, invalid entry, leading to ClassNotFound errors.
• NoClassDefFoundError: com/beust/jcommander/... — TestNG depends on jcommander for parsing command-line arguments. Add jcommander.jar to the classpath, which the libs/* wildcard does automatically.
• Your test class is not found — the compiled .class folder (bin or out) is missing from the classpath, or you used a simple name instead of the fully qualified com.example.LoginTest.
• Unquoted wildcard or path with spaces — always wrap the classpath in quotes ("bin;libs/*") so the shell does not expand or split it before java sees it.

Cross-Browser TestNG Runs on the Cloud Grid

Running TestNG locally proves your tests pass on one browser and one operating system. Real users, however, arrive on dozens of combinations, and a suite that is green on Chrome for Windows can still fail on Safari for macOS or an older version of Firefox. The fix is to run the same testng.xml against many environments at once.

With TestMu AI, you point your existing TestNG and Selenium suite at a remote hub and execute it across 3000+ real browsers and operating-system combinations on a real device and browser cloud. Because TestNG already supports parallel execution through the thread-count attribute, you can fan a regression run out across many browsers and finish in a fraction of the time. Pair it with cross browser testing to catch environment-specific failures before release.

// Point your existing TestNG @Test at the cloud grid
DesiredCapabilities caps = new DesiredCapabilities();
caps.setCapability("browserName", "Chrome");
caps.setCapability("platformName", "Windows 11");

WebDriver driver = new RemoteWebDriver(
    new URL("https://USERNAME:[email protected]/wd/hub"), caps);

// Your @Test methods run unchanged — only the driver target moves to the cloud

You still launch the run the same way — java -cp "bin;libs/*" org.testng.TestNG testng.xml or mvn test — so nothing about your command-line workflow changes; only the WebDriver endpoint moves to the grid.

Conclusion

Running TestNG from the command prompt comes down to three things: compile your classes, put the TestNG and jcommander jars on the classpath, and invoke org.testng.TestNG against your suite — using a semicolon separator on Windows and a colon on Linux or macOS. The testng.xml route is the most maintainable, the -testclass flag is fastest for one-off checks, and mvn test is the smoothest for CI. Get the suite right locally, then scale it across real browsers to ship with confidence.

Frequently Asked Questions

What is the command to run TestNG from the command prompt?

After compiling, run java -cp "bin;libs/*" org.testng.TestNG testng.xml on Windows, or swap the semicolon for a colon (bin:libs/*) on Linux and macOS. The org.testng.TestNG class is the runner, and testng.xml lists the tests to execute.

Do I need Maven to run TestNG from the command line?

No. You can run TestNG with plain java by placing the testng and jcommander jars on the classpath. Maven is optional but convenient: mvn test reads the suiteXmlFiles entry in your pom.xml and runs the suite without you building the classpath by hand.

Why do I get NoClassDefFoundError for jcommander when running TestNG?

TestNG depends on the jcommander library for command-line parsing. If you only put testng.jar on the classpath, jcommander is missing. Add jcommander.jar, or use a wildcard like libs/* so every jar in the folder is included automatically.

What is the classpath separator for TestNG on Windows versus Linux?

On Windows the separator is a semicolon (bin;libs/*). On Linux and macOS it is a colon (bin:libs/*). Using the wrong separator silently drops jars from the classpath and triggers a ClassNotFoundException.

Can I run a single TestNG class without testng.xml?

Yes. Pass the fully qualified class name with -testclass, for example java -cp "bin;libs/*" org.testng.TestNG -testclass com.example.LoginTest. You can also pass -groups or -methods to filter what runs without writing a suite file.

Can I run multiple testng.xml files from the command line?

Yes. The org.testng.TestNG runner accepts several suite files as arguments, so java -cp "bin;libs/*" org.testng.TestNG smoke.xml regression.xml executes both. TestNG merges them into one run and generates a single combined report, which is handy when you keep separate suite files but want to run them together.

How do I set the classpath before running TestNG?

Instead of passing -cp every time, set it once as an environment variable. On Windows run set classpath=bin;libs/*, then simply java org.testng.TestNG testng.xml. On Linux or macOS use export CLASSPATH=bin:libs/* with a colon separator. This keeps the run command short when the classpath is long or reused often.

• Can you describe the major features of TestNG?
• List out various ways in which TestNG can be invoked?
• How do I write and run test scripts in Selenium?
• What are the testing types that can be supported by Selenium?
• How do we use Cucumber in Selenium?
• How do I install Selenium and set up the environment for testing?