Free Articles, Free Web Content, Reprint Articles
Friday, December 4, 2020
Free Articles, Free Web Content, Reprint ArticlesRegisterAll CategoriesTop AuthorsSubmit Article (Article Submission)ContactSubscribe Free Articles, Free Web Content, Reprint Articles

Organize and manage test cases with TestNG

What is TestNG ? TestNG is a unit testing framework like JUnit. But TestNG has more features. When integrated with selenium, you can organize and manage your tests more efficiently. With a wide range...

What is TestNG ?

TestNG is a unit testing framework like JUnit. But TestNG has more features. When integrated with selenium, you can organize and manage your tests more efficiently. With a wide range of annotations provided by TestNG, you can achieve grouping, sequencing, prioritization, parameterization of your test cases along with listener interfaces, where you can perform a wide range of operations on a particular event. It also gives us the power to perform parallel execution of our test cases through xml. You can create multiple XML suites like regression suite, sanity suite, smoke suite, and configure these suites in the main testng.xml.
We'll see one by one how these can be achieved through TestNG.



Writing and executing first TestNG test

In TestNG we use @Test annotation to define our test method or test case. So any method on which @Test annotation is written is our test case or test method. In this method, you will perform the test execution and perform validation i.e. whether the actual result is matching with expected using assertion. To execute this test method, you need to define the test class in which this test method is written in testng.xml.




1. Grouping

Suppose you have multiple test classes and those test classes have multiple test methods in them. Now you want only a few from each class should be executed and not all based on your test plan. Here grouping comes into the picture where you can group your test cases/test methods belonging to different test classes. For e.g. you have a regression suite and a smoke suite. You want a few sets of test methods gets executed during smoke suite execution and another set of test methods during regression. Here there is a test class called subMenuPageTest, inside which there is a test method called checkProductClick(). As you can see from the below image, this test method belongs to "smokeTest" group. 
In the subsequent image there is our testng.xml where we have included the group "regressionTest" in our test tag.

This means execute only those test methods from class subMenuPageTest which belongs to "regressionTest" group. So when we execute this xml, only those test methods from class subMenuPageTest will be executed which belongs to the regression group and not the ones which belong to the 'smokeTest' group. 



2. Sequencing

The sequencing of test methods can be achieved through the 'priority' attribute under @Test annotation. If you have multiple test methods in your test class and you want your test cases/test methods to execute in a particular order or sequence then you can use priority attribute with @Test annotation. Zero is the highest priority. For e.g.

public void testSubmit_btn(){


public void testClick_add_icon(){


here, testSubmit_btn() will execute first, while testClick_add_icon() will execute second as priority of testSubmit_btn() is highest.




3. Parameterization

You may want to execute your tests with different sets of parameters. For e.g. you want to execute your tests on a particular browser, or on a particular OS, or on a particular environment like test, QA, UAT etc., on local environment, or on cloud etc.
For this, you can define a method accepting these parameters and based on the parameters your condition will be executed. In the below image you can see there is a method which is accepting two parameters- 'browser' and 'environment'. Based on these parameters, the respective conditions will be invoked ie. if you pass browser as 'chrome' and environment as 'local' then respective 'if' condition will be executed and chrome driver setting with local webdriver initialization will happen.

If you pass environment as 'remote' then respective 'if' condition related to remote web driver setting will execute where remote webdriver initialization will happen.



Now you might be wondering where does this parameter passing will happen? This parameter passing will be happened through testng.xml
In the below image you can see that we are passing 'chrome' as browser, and 'local' as environment.



4. Parallel execution of tests

You have seen the structure of our testng xml. There is a suite, then inside suite, there are multiple tests and these tests are mapped with test classes.
You might want to execute all your tests specified in the testng.xml in parallel or simultaneously.

To do so you can set the 'parallel' attribute in testng xml to "tests". Its default value is "None". By changing it to "tests", all your tests starts executing simultaneously.




5. Configuring multiple suites

You can also create multiple xml suites and configure these suites in testng.xml file.
Instead of creating suite and tests in testng.xml, you can create separate xml suites and configure those suites in testng.xml.

Below are two test suites one is smoke suite and another one is regression suite.

Smoke suite:

Regression Suite:

Now configure these two suites in testng.xml
When you execute testng.xml, first smoke suite will execute and then regressionSuite. This way you can manage multiple suites as per your requirement.




6. Handling pre and post conditions in testng

You might have observed that there are some preconditions which have to be executed before executing your test case. For e.g.
Suppose you want to validate "My Account" section of Amazon, and under "My Account" you want to validate "your orders" etc.. But before reaching "My account" section you first need to login into your amazon account.

So "login" to amazon account will be one of the preconditions of your "My Account" section test case.
TestNG provides various annotations like Beforeclass, beforetest, beforemethod, beforesuite.
In the below image you can see that there is a test class called productDetailPAgeTest. This class has a test method or rather I would say a test case called addToCart().
But before adding to the cart, you need to select product or category from home page, and then select product from sub menu page and finally add the product to the cart from productDetail page.

So clicking the product on home page and then selecting the product from sub menu page are the pre conditions for executing addTocart() Test case.
So what is happening here is your previous test cases become preconditions for your next test cases. i.e. Your add to cart test case will become a precondition for checkout related test cases.
So what I've done is, I've written all my preconditions for addToCart test case under @BeforeMethod annotation.

This @BeforeMethod annotation will execute before every @Test method defined in your class. Suppose you have 5 test cases or test methods in your test classFree Articles, so the method under @BeforeMethod annotation will execute every time before execution of any @Test method of your class.

You can also put postconditions under @AfterMethod annotation which will execute every time after a @Test method is executed in a class.




7. Dataprovider

As the name suggests a Data provider method provides data to the test methods. Data provider is another attribute of @Test annotation. In the below image you will see there is a utility class "ExcelReader" which will read all the data from an external file i.e. xlsx and store the entire data into a two-dimensional array. @Dataprovider annotation will be applied to this utility method and a name is given to this dataprovider. We've given the name "readingLoginData" to this data provider.

Now our test method will call this utility method through the name of data provider i.e. "readingLoginData". and you also need to specify the class name where this dataprovider resides.

Also please note that this test method testInvalidLogin() will accept as many parameters as there are columns in datasheet. For e.g. if datasheet has two columns namely "username" and "password" then the test method should accept these two as parameters.
Another point to note is this @Test method i.e. testInvalidLogin() will execute as many times as there are number of rows in data sheet. For e.g. there are 4 sets of data in data sheet or excel sheet then our test method will execute 4 times each with different sets of data.




Source: Free Articles from



This is Jayesh Jamindar, but I'm more often called as JJ. I'm the owner, author, and developer of

In my current professional capacity, I'm overseeing development and testing operations as an SDET.

Home Repair
Home Business
Self Help

Page loaded in 0.185 seconds