TestNG Annotations

Testng Annotations

Testng annotations | TestNG setup/teardown methods | @BeforeSuite, @BeforeTest, @BeforeGroups,
@BeforeClass, and @BeforeMethod​ | Teardown methods​

Testng annotations

Here is a list of the standard TestNG annotations available for test methods:

@Test
@Parameters
@DataProvider
@Listeners
@Factory
@BeforeSuiteand @AfterSuite
@BeforeTestand @AfterTest
@BeforeGroupsand @AfterGroups
@BeforeClassand @AfterClass
@BeforeMethodand @AfterMethod

@Test
Let’s build the test class from the ground up; we will use the Rock Bands test class and data file as an example:

public class RockBandsTest {
// setup/teardown methods

@BeforeSuite
protected void suiteSetup(ITestContext context) throws Exception {
}

@AfterSuite
protected void suiteTeardown(ITestContext context) throws Exception {
}
@BeforeTest
protected void testSetup(ITestContext context) throws Exception {
}

@AfterTest
protected void testTeardown(ITestContext context) throws Exception {
}

@BeforeGroups
protected void groupsSetup() throws Exception {
}

@AfterGroups
protected void groupsTeardown() throws Exception {
}

@BeforeClass

protected void testClassSetup() throws Exception {
}

@AfterClass
protected void testClassTeardown() throws Exception {
}

@BeforeMethod
protected void testMethodSetup(ITestResult rslt) throws Exception {
}

@AfterMethod
protected void testMethodTeardown(ITestResult rslt) throws Exception {
}

// testcases
@Test
public void tc001_getBandInfo(String rowID,
String description,JSONObject
testData)throws Exception {
}
}

Let’s discuss a few of the more common ones in the following example:

@Test(groups={“POSITIVE”, “NEGATIVE”,”BOUNDRY”,”LIMIT”,”SMOKETEST”,”REGRESSION”},   dataProvider=”fetchData_JSON”,dataProviderClass=JSONDataProvider.class,enabled=true,alwaysRun=true,priority=1)

public void tc001_getBandInfo() {

}

When the groupsattribute is used, it allows the user to tag specific test cases to be part of an overall group, a subset, or a feature test set.

So, in this example, the user defines which group or groups to run in the TestNG suite XML file, and only that subset of groups will be run. It makes sense to tag only a couple of test methods in each class as SMOKETEST, so as you develop the functional test classes, you build a SmokeTest at the same time and “most” of the test methods would be tagged REGRESSION, except for the LIMITtests, which would stress out or break the product.

The next two attributes in the example, dataProviderand dataProviderClass, are used to tell TestNG which DataProvider class and method to use to extract data to pass to the test method. The last chapter covered building the JSON DataProvider; this is where the user calls it. The enabledattribute tells TestNG whether or not the test method should be run; great for disabling tests that aren’t working, are blocked by defects, or for debugging purposes.

The dependsOnMethodsattribute will tie the test method to other test methods in the class. This is a rather tricky one to use, as it will force all test methods to “skip” if the dependent method fails. It is at times more practical to set up a test class using one of the setup/teardown annotations rather than using this attribute.

The alwaysRunattribute tells TestNG to run the test method regardless of a failure to a method it may depend on. And finally, the priorityattribute tells TestNG which priority order to run the tests in. The TestNG documentation covers all the attributes in detail; we’ve discussed a few of the more common ones here.

TestNG setup/teardown methods

In the previous Rock Bands test class example, we listed some of the annotations that tell TestNG whether a certain method should be run before or after certain points in time during the test run. These are the setup and teardown methods. They come before and after a suite, test, groups, class, and method.

As simple as it may seem, there are various rules and orders of precedence when using them. Let’s look at some examples.

Setup methods in TestNg

When you build the test class, there will be certain Java methods annotated with @Test, which tells TestNG that the method is a test and should be run. Those tests will run in random order by default except, if you use a dependent method, a sequential naming scheme, or a priorityattribute. That will force the tests to run in a specific order.

For all the methods in a suite of tests, there will be common actions that need to be executed before each suite, test, groups, class, or methods, and instead of calling the same setup method in each class or test, for instance, it makes sense to do them in one place. Using the TestNG setupannotations will allow users to execute a routine in a central place.

TestNG annotations : @BeforeSuite, @BeforeTest, @BeforeGroups, @BeforeClass, and @BeforeMethod

Let’s discuss each annotation in detail:

@BeforeSuite: All the methods called in this setup will get executed before anything else runs in the suite. For instance, if you want to invoke the browser or a mobile device, you could call the create driver method in @BeforeSuite, and it would launch the application, maximize it, and load the URL (browser) before running the test class methods. This is also a good place to retrieve parameters using the @Parameters annotation from a Jenkins build process, system property via JVM arguments, and system environment variables. They can then be processed here for use throughout the suite. Remember, TestNG defines a suite as all the tests contained in the suite XML file.

TestNG annotation @BeforeTest : All the methods called in this setup will run before all test packages or classes defined in the tag section of the XML file. If building tests to run in parallel at the level, users would want to invoke the browser or mobile device here, so each “thread” would run in its own browser or mobile device. This is also a place where @Parameters can be used, which can be defined in the XML file as well in each section. The sections in the XML can contain the same or different test packages or classes, and this annotation is a way to execute an application setup procedure for all of them.

TestNG annotation @BeforeGroups: All the methods called in this configuration setup will run before a specific group or groups of tests run. The @Test attribute groups=would need to be used for this to have any effect. This annotation allows a different setup procedure to be run for different groups of tests.

TestNG annotation @BeforeClass : All the methods called in this setup will run before the first test method runs in the current class. In each test class, there may be a specific setup that is required before any of the test methods in the class run. This would include such things as creating default users, accounts, setting up default preferences in the application, and so on.

TestNG annotation @BeforeMethod : All the methods called in this setup will run before each and every iteration of a test method has run. Users often use this method to set the application to a known “app” state so that each test starts at the same place, avoiding conditions where failed tests leave the application in a weird state, windows left open, and so on.

Teardown methods in TestNG

For all the methods in a suite of tests, there will be common actions that need to be executed after each suite, test, groups, class, or methods, and instead of calling the same cleanup method in each class or test, for instance, it makes sense to do them in one place. Using the TestNG teardown annotations will allow users to execute a routine in a central place, as it did with the setup annotations.

TestNG annotations : @AfterSuite, @AfterTest, @AfterGroups, @AfterClass, and @AfterMethod

Let’s discuss all the annotations in detail:

TestNG annotation @AfterSuite : All the methods called in this teardown will execute after everything else has completed in the suite. This is a good place to clean up the AUT, delete
users, and accounts created during test runs, uninstall mobile applications, and close the browser or mobile device. If a report listener is being used, the report could be constructed in this method after all the TestNG results are collected.

 

TestNG annotation @AfterTest : All the methods called in this teardown will run after all the test packages or classes defined in the tag section of the XML file have completed. If running sections in parallel, users can use this to close the browsers or mobile devices in each thread, provide cleanup, delete users, and so on.

TestNG annotation @AfterGroups : All the methods called in this configuration teardown will run after a specific group or groups of tests run. Because test methods generally run in a random order with TestNG, this method will run at some point after the last test method runs in the section of the XML file.

TestNG annotation @AfterClass : All the methods called in this teardown will run after the last methodvruns in the current class. This teardown is very useful for cleaning up all leftover users, accounts, settings, or anything else the @AfterMethodroutine fails to remove. This is also a good place to process TestNG results (ITestResult) for reporting purposes.

TestNG annotation @AfterMethod : All the methods called in this teardown will run after each and every iteration of a test method has run. What that means is that when running data-driven tests, a single test method may execute multiple times, and this cleanup method will run after each iteration. This routine is useful for cleanup when exceptions occur during a test method run, taking screenshots, reporting results, and generally setting the application back to a known “base” state.

Author: Saad Mansuri

Leave a Reply

Your email address will not be published. Required fields are marked *