Units

A unit represents an actionable component in your model, such as log in or purchase. You combine units to create a model for testing.

Unit overview

Each unit represents an action in your application. You create units for each action, and then build a model showing the possible flows between these units. To automate testing, each unit should correspond with a test in your Git repository.

Units can be created in different ways.

Method Details
Auto-discovery

Units can be created automatically, based on tests stored in a Git repository. Configure a connection to your repository. Units associated with the tests are automatically populated. For details, see UFT One tests as MBT units.
Manual creation

Create units in MBT, and then connect them with scripts or tests that describe the steps they run. You can do any of the following:

  • Connect your units to Selenium or OpenText Functional Testing tests in your Git repository or Execution storage.

  • Link your units to manual tests.

  • Manually create a unit and describe its steps.

  • Use Aviator to automatically generate codeless scripts from the manual tests linked to your units. For details, see To automatically generate a codeless script from a unit's manual test.
Convert model placeholders to units

You can manually build MBT models with placeholders to represent your application’s business processes.

You can generate models with Aviator, based on feature descriptions.

Then, convert the placeholders in the model into units. For details, see Models.
Import from file

Import a model from a BPMN or JSON file. For details, see Import a BPMN file.
FT Design Use Functional Testing Design to write test scripts for your units. For details, see Create a unit in Design.

A unit can be assigned to multiple MBT models and tests. If you modify a unit, the change is applied to all related tests and models.

Create a unit manually

This section describes how to create and configure a unit manually. The instructions on configuring units are also relevant for auto-discovered units.

To create and configure a unit:

  1. Select a model folder in the MBT repository pane, or create a new model folder. This structure enables you to organize your MBT models and units in a way that is meaningful to you.

  2. In the Units tab, click + Unit.

  3. Provide a unit name that describes the action it performs.

  4. (Optional) In the Steps tab, add unit steps as you would in a manual test. Adding steps let you describe a unit's detailed actions without linking it to a separate manual test. For details on using the Steps tab, see the OpenText Core Software Delivery Platform Help Center.

    If a unit contains steps, they are reflected in the Manual Runner when you run the test, and in the Manual Run report. This enables you to pinpoint MBT test run failures more easily.

    Note: In the report, you can expand each unit to see its steps' details. Each step is displayed with its status, expected value, and actual value, depending on the information entered during the test run.

    Step details are available only for runs performed after the steps were added to the unit.

  5. In the Details tab, describe the purpose of the unit, and fill any other fields that are relevant. We recommend that you configure the details described in the following table.

    Field Description
    Automation status

    Specify whether the test covering this unit is automated in your CI server.

    When you create an MBT test that covers this unit, the test indicates what percentage of the test's units are automated, helping you optimize your automation strategy.
    Repository path

    If the unit has a corresponding test script in Git, enter the path to the test script in the repository that is defined in MBT settings.

    Do not enter the full path to the test script, but only the relative path inside the repository. For example, if a test is located inside <Git repository URL>/UFTtests/Action1, the Repository path is UFTtests/Action1:ActionName.

    Note: When you use auto-discovery to populate units, each unit is automatically assigned a test runner on creation based on its Git URL. You can then see the unit's runner using the optional Test runner field. This helps ensure that all units in a path use the same test runner.
    Testing tool type Define the testing tool that will be used to run the automated script.
    Priority

    You can add the Priority field if needed.

    If you choose High or Low priority, this is indicated on the unit's card and in the preview pane.
    Phase

    Select the unit's phase. MBT uses phases to represent the current state of an item. As you work on items, advance them from phase to phase.

    When you set a model's phase to Ready, the icon representing the model changes color.

  6. (Optional) In the Parameters tab, click + Unit Parameter to create input or output parameters for the unit.

    Use parameters to pass values between units and to run the same test multiple times with different values.

    For example, a unit can search for a book using an input parameter for the title, and output the book's internal item ID. The next unit can use that item ID as an input parameter.

    You can also create data sets with multiple rows. When you run the test, each iteration uses one row of parameter values.

    Note: If you use parameters in a unit, you must include the parameter names in the unit name, enclosed in <> brackets. Otherwise, parameter values are not passed to the unit.

    Example unit name: Log in to the server with<Username> and <Password>

    1. For each parameter, define the following:

      • Type. Enter either Input or Output.

      • Name. Enter a name for the parameter.

      • Default value is optional.

    2. When parameters are used in an OpenText Functional Testing action or Selenium test, the following are required:

      • The parameter name must be identical in MBT and in the testing tool. To rename a parameter, click on the parameter name and edit as needed.

      • The order of the parameters in the unit must be identical in MBT and in the testing tool. To reorder parameters, select a parameter and click Up or Down in the toolbar.

Create a unit in Design

Supported only on OpenText Core Software Delivery Platform.

Functional Testing Design enables you to create codeless tests and run them in the cloud. For details, see Create a script.

In this workflow, you use FT Design to write test scripts for your units. The test script is saved in FT Design and not in Git. You then schedule and run the tests using Functional Testing Execution. For details, see Execution.

If you want to associate your unit with a codeless script, and you already have the relevant steps described in a manual test, you can harness the power of AI, and have Aviator generate the codeless scripts based on your manual tests.

To create codeless scripts manually with FT Design:

  1. In an MBT unit, click Create in Design. FT Design opens locally.

  2. Create your codeless test script in FT Design. For details, see Create a script.

  3. After saving the script in FT Design, click View in Model-Based Unit, or refresh the unit in MBT.

    The testing tool type is automatically defined as FT Design. The repository path is automatically filled with an internal file name, and the automation status is set to Automated. These cannot be changed. If needed, delete the unit.

  4. Schedule and run the tests using Functional Testing Execution. Select the test runner called Codeless Runner. For details, see Execution.

Tip: You can also perform this process in the opposite direction:

First, create a script in FT Design, then click Associate with > New Codeless Unit. A new unit is created in MBT, in a folder called VEFT Design.

To move the unit to another folder, add the Parent field in the grid view and select a different folder in the MBT repository.

To automatically generate a codeless script from a unit's manual test:

Requires an Aviator license

  1. Create a unit.

  2. Link a manual test to the unit. For details, see Manual tests.

  3. On the Details tab of the unit, click Create in Design.

  4. Click Generate a new Codeless script...., then click Continue.

A new script is created, based on the steps in the linked manual test, and associated with the unit.

An AI-generated script may be inaccurate and incomplete. Make sure to review it in Design and ensure that it runs locally before running it as part of an MBT test. When the script is ready, click Open in Design to review and edit the script. For more details, see Refine the generated scripts.

  • The test steps are written in plain English and identify objects in your application visually, as a person would.

  • The generated script has the same name as the manual tests it is based on. If the manual test name contains any characters not supported in script names, those characters are omitted from the script name. See Naming conventions.

  • The script is stored in Functional Testing Design, in a folder named Generated from manual and a subfolder based on the script's creation date.

  • After you refresh the unit, the following fields are updated automatically: 

    Field New value
    Automation status Automated
    Testing tool FT Design
    Test runner Codeless Runner
    Repository path The new script's location

The manual test also remains linked to the unit, but is not related to the codeless script. If you update your manual test and want to update the codeless script, unassociate the existing codeless script, and generate a new one.

See also: