Let's say you want to run a test suite against a specific browser, platform, and environment, then re-run it on a different browser and platform. Using TestNG's @Parameters allows you to change the settings in the suite XML file and process them in the setup class. Where you process them depends on when you want to invoke the browser or mobile device.

Using the previous example, we added them to the <test> section of the suite file, so the driver will be created before any of the test classes are run. So in the common setup class, you would add @Parameters to the @BeforeTest method:

@Parameters({"browser", "platform", "environment"})
@BeforeTest(alwaysRun=true, enabled=true)
protected void testSetup(@Optional(Global_VARS.BROWSER) String browser,
                         @Optional(Global_VARS.PLATFORM) String 
                         platform,
                         @Optional(Global_VARS.ENVIRONMENT) String env,
                         ITestContext context)
                         throws Exception {

    // setup driver
    CreateDriver.getInstance().setDriver(browser, platform, env);
}

Notice the use of the @Optional annotation. This allows users to set a default value, which must be a constant, for each parameter. This provision is for cases where the user doesn't set them in the suite file. In other words, now that you have set up defaults for the browser, platform, and environment, it is optional whether or not they are passed in.

Here is an example on the mobile side:

// suite xml file

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE suite SYSTEM "http://testng.org/testng-1.0.dtd">

<suite name="My_Test_Suite" preserve-order="true" parallel="false" 
thread-count="1" verbose="2">

    <!--  tests -->
    <test name="My Test">
        <!-- test parameters -->
        <parameter name="browser" value="safari" />
        <parameter name="platform" value="iphone" />
        <parameter name="environment" value="saucelabs" />
        <parameter name="mobile" value="iPhone 8 Simulator" />

        <packages>
            <package name="my.tests.*" />
        </packages>
    </test>
</suite>

// common setup class

@Parameters({"browser", "platform", "environment", "mobile"})
@BeforeTest(alwaysRun=true, enabled=true)
protected void testSetup(@Optional(Global_VARS.BROWSER) String browser,
                         @Optional(Global_VARS.PLATFORM) String 
                         platform,
                         @Optional(Global_VARS.ENVIRONMENT) String env,
                         @Optional(Global_VARS.MOBILE) String mobile,
                         ITestContext context)
                         throws Exception {

    // setup driver
    Map<String, Object> prefs = new HashMap<String, Object>();
    prefs.put("deviceName", mobile);
    CreateDriver.getInstance().setDriver(browser,
                                         platform,
                                         env,
                                         prefs);
}

The difference here is that when we created the Selenium CreateDriver class, we only allowed three parameters to be passed into the setDriver method. Any other capabilities must be set on the fly by creating a map and passing that map in as a variable argument to the method.