TestNG Visualizer

Annotation execution order

TestNG runs annotations in a fixed order that you should be able to recite: @BeforeSuite → @BeforeTest → @BeforeClass → @BeforeMethod → @Test → @AfterMethod → @AfterClass → @AfterTest → @AfterSuite. The before hooks fire outermost-first and the after hooks fire innermost-first, wrapping each test method.

Priorities, dependencies and groups

priority orders tests (lower runs first; same priority runs alphabetically). dependsOnMethods skips a test if its dependency failed. Groups tag tests (@Test(groups="smoke")) so a suite XML can include or exclude them — the TestNG equivalent of Cucumber tags.

Data providers: data-driven testing

A @DataProvider method returns a set of rows, and TestNG runs the test once per row. This is the clean way to test many inputs without duplicating test methods, and it is the standard TestNG interview answer for data-driven testing.

Parallel execution

TestNG can run methods, classes or tests in parallel via the suite XML (parallel="methods" thread-count="4"). This is a major reason large Selenium suites use TestNG — but your tests must be thread-safe (no shared mutable driver), which is exactly why teams use a ThreadLocal WebDriver.

How to use this tool

1. Run the sample suite and watch each annotation fire in order.
2. Add priorities to test methods and see the order change.
3. Attach a data provider and watch the test repeat per data row.
4. Enable parallel execution and see methods run on multiple threads.

Worked example

A data-driven TestNG test runs once per row returned by the provider:

@DataProvider(name = "logins")
public Object[][] logins() {
    return new Object[][] {
        {"admin", "pass1"},
        {"user",  "pass2"}
    };
}

@Test(dataProvider = "logins")
public void login(String user, String pass) {
    loginPage.login(user, pass);
    Assert.assertTrue(homePage.isLoaded());
}

Common mistakes to avoid

• Assuming test methods run top-to-bottom — without priorities, order is alphabetical.
• Sharing one WebDriver across parallel threads instead of a ThreadLocal instance.
• Putting setup in @Test methods instead of @BeforeMethod.
• Using dependsOnMethods to fake an order that priority or grouping would express better.

Frequently asked questions

Related guides & tools