Name: Selenium Java Tutorial with TestNG
Availability: InStock

Ten questions on the decisions this course made and why; each answer explains the reasoning once you check.

1. A teammate's README says to download chromedriver and set webdriver.chrome.driver before running the suite on Selenium 4.52. What is the best advice?

Keep it: Selenium cannot start Chrome without a manually installed driver. Remove it: Selenium Manager resolves and caches a matching driver, and a stale driver on the PATH can cause version-mismatch errors. Replace it with a newer chromedriver checked into the repository.

Since Selenium 4.6, Selenium Manager finds or downloads the right driver automatically. A manually placed driver takes precedence and is the usual cause of "this version of ChromeDriver only supports Chrome version N".

2. You upgrade maven-surefire-plugin from 3.5.6 to 3.6.1 and mvn test now stops before running anything. Why?

Surefire 3.6 requires Java 25. TestNG 7.12 is not compatible with Maven 3.9. Surefire 3.6 runs TestNG on the JUnit Platform, which cannot read the suiteXmlFiles configured in the pom.

From 3.6.0 all frameworks run through the JUnit Platform and suiteXmlFiles is rejected. Either stay on 3.5.x or replace suite files with groups and includes.

3. Every test method in a <test> block is unexpectedly sharing one browser. Where was the driver most likely created?

In a @BeforeTest method. In a @BeforeMethod method. In the test method itself.

@BeforeTest runs once per <test> tag in testng.xml, not per test method. Per-test browsers belong in @BeforeMethod.

4. You run mvn test -Dgroups=smoke and every smoke test fails with a NullPointerException on the driver. What is the fix?

Add the smoke group to every test class. Add alwaysRun = true to the @BeforeMethod and @AfterMethod that manage the driver. Increase the explicit wait timeout.

With a group filter, configuration methods that are not in that group are skipped unless they declare alwaysRun = true, so the driver is never created.

5. A test calls Assert.assertEquals("Received!", message.getText()) and fails with "expected [Error] but found [Received!]". What happened?

The page really showed "Received!" and the test is wrong to fail. TestNG swapped the values because of a bug. The arguments are in JUnit order; TestNG expects actual first, so the page showed "Error" and the message reads backwards.

TestNG's signature is assertEquals(actual, expected). Passing them JUnit-style still fails at the right time but produces a misleading message.

6. A test creates a SoftAssert, makes five checks, three of which fail, and the test passes. What is missing?

A call to softly.assertAll() at the end of the test. A @Listeners annotation for SoftAssert. alwaysRun = true on the test.

SoftAssert only records failures. assertAll() is what throws them; without it they are discarded and the test passes.

7. You set parallel = true on a data provider while the base class still keeps the driver in a plain instance field. What do you expect?

It works, because each data row gets its own instance of the test class. Random failures such as NoSuchSessionException, because all rows share one instance and overwrite each other's driver. TestNG refuses to start because the provider is not static.

All invocations of a data-driven test use the same instance. Without a ThreadLocal<WebDriver>, threads replace and quit each other's browsers.

8. Your suite has thread-count="3" and a parallel data provider with 20 rows, yet far more than 3 browsers open at once. Why?

thread-count is ignored when parallel="methods". Selenium Manager starts extra browsers to warm its cache. Parallel data providers use a separate pool sized by data-provider-thread-count, which defaults to 10.

The suite pool (3) and the data provider pool (default 10) are independent. Set data-provider-thread-count explicitly when browsers are a limited resource.

9. Your screenshot listener runs in onTestFailure, and the driver is quit in @AfterMethod. Does the screenshot show the failing page?

Yes: TestNG calls onTestFailure before the @AfterMethod configuration methods, so the browser is still open. No: @AfterMethod always runs first, so the driver is already gone. Only if the listener is registered with @Listeners rather than testng.xml.

With TestNG 7.12, onTestFailure runs on the test's thread before teardown, so BaseTest.driver() still returns the live session. Where the listener is registered does not change the order.

10. On a remote grid, a test fails on an assertion but the grid's dashboard shows the session as completed without a failure. Why, and what fixes it?

The grid lost the result; rerun the test. The grid only sees WebDriver commands, not your assertions; report the outcome, for example with tb:test-result=failed via the JavaScript executor before quit(). Assertions are disabled on RemoteWebDriver; switch to SoftAssert.

Assertions run in your JVM. The grid can only know the outcome if you send it, which the final BaseTest does in @AfterMethod using ITestResult.isSuccess().

Where to go next#

Your suite now has one browser per test, safe parallelism, screenshots on failure and a switch to run on a grid. The next step is structure: once several tests touch the same pages, move locators and page interactions into page objects, which the Page Object Model course builds on top of a project like this one. If you are preparing for a job interview, the test automation interview questions course has a chapter on TestNG questions. For the reference version of the grid setup, keep the TestNG documentation at hand.

Knowledge check

Where to go next#

You finished Selenium Java Tutorial with TestNG