Add steps to your tests

To run steps on your application, create steps containing UFT Developer test objects, methods, and properties.

Alternatives for creating test object descriptions

The Application Model editor and OIC enable you to generate test object description code automatically. Alternatively, you can write out your test object description code programmatically.

  • After creating a programmatic description for a UFT Developer test object, create steps that perform operations or retrieve values from your application objects. Use IntelliSense (for C# or Java) to select the relevant test object methods or properties.
  • You can check whether your application looks and acts as expected, using UFT Developer Verification methods. For details, see Verifications.
  • If the test object methods and properties for an object do not provide the functionality you need, you can access the native properties and methods of an object. For details, see Access native objects, methods, and properties.
  • Make use of standard code and the capabilities provided by the testing framework you chose, together with UFT Developer SDK code to create comprehensive tests that cover all aspects of your application.
  • You can use the GetDescription method to return an object's description. If used on objects returned by the FindChildren method, GetDescription returns a NULL value, as these objects were never identified using a description.

Back to top

Code programmatic test object descriptions

To create programmatic test object descriptions in your test, follow the steps below:

  1. At the top of your test file, specify the SDK elements you plan to use by providing the required statements:

    Language File Statement
    C# .cs using
    Java .java import
    JavaScript .js var

    For example, if you want to create steps using the UFT Developer core SDK as well as Web and Standard Windows technology objects, use the following:

  2. Determine the top-level parent object for your test, depending on the application type:

    Web-based applications

    The browser is the top-level parent test object. You use the BrowserFactory.Launch method to create to create a new instance of the Browser test object.

    Tip: You can alternatively use the BrowserFactory.Attach method to run steps on an existing open browser. This also creates a Browser test object instance.

    Windows-based applications A window or dialog box is the top-level test object. You use the Desktop.Describe method to create a Window or Dialog test object.
    Mobile applications The device is the top-level test object. Use one of the MobileLab.LockDevice* methods to create an instance of the Device test object.
    SAP GUI for Windows applications

    The SAP GUI session is the top-level test object. You use the GuiSessionFactory.Launch method to create a new instance of the GuiSession test object.

    Tip: You can alternatively use the GuiSessionFactory.Attach method to run steps on an existing open SAP GUI session. This also creates a GuiSession test object instance.

  3. Determine the test object hierarchy for the test object. Most objects have a minimum of a two level hierarchy, but in some cases you may need to, or choose to, provide a deeper hierarchy.
    Possible hierarchies could be: browser> page > edit or window > button.

    You can use the OIC to view the recommended hierarchy for a specific object. For details, see Object Identification Center.

    Create each test object as a child of the relevant parent object.

  4. Determine the set of properties you want to use to describe your object.

    Tip: Use the OIC to find the available test object properties and current values for the object in your application.

    From the OIC, you can also copy the code for a test object description to the clipboard and paste it into your test.

    For details, see Object Identification Center

  5. Create a new child object using the Describe method (C#/Java) /.$ (JavaScript) and the corresponding <TestObjType>Description object (C#/Java) that provides access to the relevant identification properties. Then provide property-value pairs that uniquely identify the object.

    The basic syntax is as follows:

    To specify a property value using a regular expression, use the following syntax:

    C#IDProp = As.RegExp(@"RegExpValue")
    Java.idProp(new RegExpProperty("RegExpValue")

Note: When comparing String values in a description with the property values in the application’s objects, leading and trailing spaces are trimmed from both values.

When comparing regular expressions in a description with String values in the applications objects’ properties, leading and trailing spaces are trimmed only from the value in the application.

Back to top

Regular expression guidelines

When using regular expressions in test object descriptions, follow these guidelines : 

  • For C# and Java, specify regular expressions using VBScript regular expression syntax.  For example, to indicate any number of characters in a string, use .* and not just the * expression.

  • For JavaScript, use standard JavaScript syntax.  However, option flags are not supported and are ignored.

  • By default, all regular expressions in descriptions are anchored to the beginning and end of the search string.

  • Regular expressions are not supported for Mobile test objects.

Back to top

Secure sensitive information

When a test must contain sensitive information, such as user names or passwords, to access the application being tested, you can use the UFT Developer SDK to make this sensitive data harder to access.

  1. Use the Password Encoder tool to generate an encoded string resembling a mix of jumbled characters. This prevents the password from appearing in cleartext.

    Caution: The Password Encoder tool does not use a global standard for encryption. It is not considered nor is it intended to be secure. Its only purpose is to ensure that passwords do not appear in cleartext while editing or running a test. The actual passwords and/or data are stored with your test's source code. If you are using real customer data or other sensitive information, you should take additional steps to ensure the security of that data.

    Run the Password Encoder tool as follows:

    • From the UFT Developer Start menu
    • In your IDE after installing the UFT Developer plugin: UFT Developer > Tools menu

    In Terminal:

    1. Change to the <UFT_Developer_installdir>/Tools directory
    2. Run ./password-encoder <password-to-encode> [-me], where <password-to-encode> is the password you want to encode.

  2. When entering a password into a password field, use the generated string as the argument for a <TestObject>.SetSecure step (instead of the normal Set method). This hides the password, preventing it from being displayed in cleartext, but does not fully secure the password.

    For usage details, see the relevant SDK Reference.

Back to top

Run desktop applications using the UFT Developer SDK

You can write test code to launch a desktop application using the launchAut() method. This method is available in all UFT Developer SDKs (.NET, Java, and JavaScript). For security reasons, in order to launch an application using this method, you must add the application and the format in which you are running it to a allowlist file.

If this is your first time using the launchAut() method, you need to create the allowlist file. If you have already created the file, add the new applications to the file. In either case, review the File format section for instructions.

Note: You must restart the UFT Developer engine after you add an AUT to the autConfig.json file. For details, see Start/Stop the runtime engine.

To create an allowlist file

Create a file called autConfig.json in the following location:

Linux ~/.leanft/config
Mac ~/Library/Application Support/LeanFT/config
Windows %localappdata%\LeanFT\config\

File format

The file is in JSON format.



Includes the applications that you want to launch using the launchAut() method.

If you want to launch the same application in different ways, make sure to add an entry for each way.

fileName The application name. You can specify the name only, with or without the extension, the relative path or the full path.
args An array of arguments. For example, command line arguments.
workingDirectory The current working directory of the application.

The following is an example of an autConfig.json file. It demonstrates different ways for specifying a desktop application.

    "allowedAuts": [
            "fileName": "C:\\Windows\\System32\\calc.exe"
            "fileName": "mspaint.exe"
            "fileName": "mspaint",
            "args": ["C:\\devTools\\img\\2.png"]
            "fileName": "mspaint",
            "args": ["1.png"],
            "workingDirectory": "C:\\devTools\\img"

This file corresponds to the following launchAut() implementations:

Aut calc = Desktop.launchAut("C:\\Windows\\System32\\calc.exe");
Aut mspaint1 = Desktop.launchAut("mspaint.exe");
Aut mspaint2 = Desktop.launchAut("mspaint", "C:\\devTools\\img\\2.png");
Aut mspaint3 = Desktop.launchAut("mspaint", new String[] {"1.png"}, "C:\\devTools\\img");

You can find launchAut() code samples here:

Back to top

See also: