Parameterizing Test Object properties

The same TOs might appear in different flavors. For example, a Submit button in a localized English version would show the text Einreichen for the German version. If the objects were given abstract IDs not related to their function or displayed text, then life for the automation developer would be easy; however, this is generally not the case. As managing a separate object repository for each language would pose a maintenance impasse for any automation project, a more practical approach should be adopted. A good alternative is to store the values for identification properties that change from one environment to another in an external data source, which is loaded at the beginning of a run session according to the required language. This recipe will show how to parameterize an identification property for a given TO and use the dynamically loaded value to identify the object during runtime.

How to do it...

In this recipe, we will take the Google+ Sign In button, which carries a different text value for each localized version. In our example, we will learn about the button in one language (Afrikaans), store the TO in a single Object Repository (OR), and make it get the value for its name attribute from an Environment variable named Google_Sign_In. The Environment variables for the test will be loaded according to the application language (refer to the Using global variables (Environment) recipe in Chapter 8, Utility and Reserved Objects).

Proceed with the following steps:

1. With UFT already up, the Web add-in loaded and the test using it, navigate to File | Settings and then open Internet Explorer. Now, navigate to the Google+ sign-in page.
2. At the bottom of the page, there is a list from which one can select a language; select Afrikaans.
3. In UFT, navigate to Resources | Object Repository... (or use the Ctrl + R shortcut), as shown in the following screenshot:
   
4. Click on the + icon bearing the tooltip Add Objects to Local, select the sign in button with the mouse icon, and then add it to the OR.
   
5. Click on the text to the right of the name property, and then click on the icon that appears to the right, as shown:
   
6. In the Value Configuration Options dialog that opens, select Parameter. Now, from the drop-down list in the Parameter field, select Environment, as shown in the following screenshot:
   
7. In the name field (combobox), type <Google_Sign_In>. Leave the value as is and click on OK.
   
8. In OR, you will now notice that the value of the name property has changed to <Google_Sign_in> and the icon on the left represents the Environment object.

When running the test, OR will take the value of the name property from the Environment variable. Hence, if we have a set of such values for each language, then we will be able to test an application in whichever language we choose, without having to change a single line of script code!

Note

As with this method, the value is stored as an internal Environment variable, and we wish to load the values according to the language interface under test. We need to export the environment to an external XML file and load it at the beginning of the run session.

There's more...

The same basic approach can be used for object identification with the Using Descriptive Programming inline recipe of Chapter 5, Object Identification.

See also

The Importing an Excel file to a test and Using a configuration file to manage test environments recipes.