Transcripted Summary

In this chapter, we will discuss the <parameter> tag for the TestNG XML file, the @Parameters annotation, and the different ways to supply test data.

Cross-browser testing is a form of data-driven testing because we can drive different data sets using the <parameter> tag and@Parameters` annotation.

I’m going to send different browser names from the XML file to the @Parameters annotation.

# Parameter Tag via XML File

The <parameter> tag specifies the name and value of a parameter. In this XML file, we have the same class name “Test Automation U” located in three different tests: one for Internet Explorer, one for Firefox, and one for Chrome.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE suite SYSTEM "">
<suite name="Cross Browser Testing">
	<parameter name = "URL" value = ""/>
  	<test name = "Test On IE">
	  	<parameter name = "BrowserType" value = "Internet Explorer"/>
	  			<class name = "com.testautomationu.chp8crossbrowsertesting.TestAutomationU"/>
  	</test> <!-- Test On IE -->
  	<test name = "Test On Firefox">
	  	<parameter name = "BrowserType" value = "Firefox"/>
	  			<class name = "com.testautomationu.chp8crossbrowsertesting.TestAutomationU"/>
  	</test> <!-- Test On Firefox -->
   	<test name = "Test On Chrome">
		<parameter name = "BrowserType" value = "Chrome"/>
	  			<class name = "com.testautomationu.chp8crossbrowsertesting.TestAutomationU"/>
  	</test> <!-- Test On Chrome -->  	

</suite> <!-- Cross Browser Testing -->

We have the option of placing the <parameter> tag within the <suite> level or <test> level. The <parameter> tag will get overridden at the <test> level if we add the tag in both places with the same parameter name. This is because the <test> level is the closest to the <class> level which uses the parameter name. I decide the level to place the parameter name and value by determining if all classes need the same value. If all classes need the same value then I add the <parameter> tag at the suite level. If the classes require a unique value then I add the <parameter> tag at the test level.

This XML file has different parameter names. We see URL and BrowserType. All three classes need to access the same website. Therefore, at the <suite> level, we have parameter name as “URL” in parenthesis then the value of the URL is

Next, is the <test> level. The parameter name will be the same for each test but the values are going to be different. Let’s start with a test on IE. The parameter name is BrowserType and the value is InternetExplorer. This test will use Internet Explorer as a browser.

The next test uses Firefox as the browser, and the last test is uses Chrome.

# Parameters Annotation

The purpose of a @Parameters annotation is to point out how to pass parameters and which parameters to pass to the test method.

We are going to pass the URL and BrowserType from the XML to the @Parameters annotation. The value we write in this annotation must match the parameter name from the XML file. The parameter names are URL and BrowserType.

@Parameters ( {"URL", "BrowserType"} )
public void verifyTAU (String url, String browserType) {}

Parameters in the annotation are different from parameters in the test method. Parameters in the annotation are a list of parameter names to be looked up in the XML file. Parameters in the test method receive the values from the XML file. Therefore, one gets the parameter name and the other one gets the parameter value.

Let's add code to this method to instantiate the proper driver based on the browser specified.

import org.openqa.selenium.By;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.firefox.FirefoxDriver;
import org.testng.annotations.Parameters;
import org.testng.annotations.Test;

public class TestAutomationU
	WebDriver driver;
	@Parameters ( {"URL", "BrowserType"} )
	public void verifyTAU (String url, String browserType)
		if (browserType.equalsIgnoreCase("Internet Explorer"))
			System.setProperty("", "C:\\Users\\Rex Allen Jones II\\Downloads\\Drivers\\IEDriverServer_Win32_2.53.1\\IEDriverServer.exe");
			driver = new InternetExplorerDriver ();
		else if (browserType.equalsIgnoreCase("Firefox")) 
			driver = new FirefoxDriver ();
		else if (browserType.equalsIgnoreCase("Chrome")) 
			System.setProperty("", "C:\\Users\\Rex Allen Jones II\\Downloads\\Drivers\\chromedriver.exe");
			driver = new ChromeDriver ();
		System.out.println("\n" + "Open " + browserType);
		System.out.println("   " +  driver.getTitle());
		System.out.println("Close " + browserType + "\n");

To execute this, we must run the XML file. A failure will occur if we execute from the class.

# Different Ways To Supply test data

In this chapter, we hard-coded our test data sets. However, we can also use other ways to supply our test data such as CSV file, database, properties file, or Microsoft Excel. All of the ways have their pros and cons.

# Additional Concepts

Here’s some additional TestNG concepts that were not covered in this course:

  • The ability to disable a test method by setting enable to false
  • Execute a package at runtime
  • Executing TestNG from the command prompt
  • Provide optional values using the @Optional annotation
  • Add Listeners which is a registration for test results
  • Add Logs
  • And the ability to view default reports
  • Create custom reports
  • Multithreading which executes multiple components of a program at the same time and there’s more TestNG concepts available to us

I want to end by saying thanks to Angie Jones. She’s good, I like her and thanks to Applitools. They gave me an opportunity to be your instructor for this course.

You can reach me at I have a social network that provides videos on Selenium, Java, and TestNG. The videos are available on YouTube, LinkedIn, and Facebook. I am also the author of 6 books that covers programming and automation. Some of the books are getting updated to include videos. Thank you for watching this course and I wish you much success.


© 2023 Applitools. All rights reserved. Terms and Conditions Privacy Policy GDPR