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 OpenText Functional Testing 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.

  • Use Aviator to automatically generate codeless scripts from the manual tests linked to your units. For details, see To generate a codeless script from a linked manual test.
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.

Back to top

Create a unit

This section describes how to create and configure a unit. 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. In the Details tab, enter the unit's name, and fill any other fields that are relevant. We recommend that the unit name describe the action it performs, and 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 uses 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.

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

    For example, you could have a unit whose function is to search for a book. The input parameter is the book title, and the output is the book's internal item ID. This parameter can then be the input parameter in the next unit in your model, which takes the item ID as input, and generates a price as its output parameter.

    You can also use parameters in an MBT test to run a single test several times with different values. Create data sets with multiple lines of data. When you run your test, it runs iteratively, using one row of parameter values from the data set for each iteration.

    Note: If you use parameters in a unit, you must include the parameter names in your unit's name, enclosed in <> brackets. Otherwise, the 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.

Back to top

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 generate a codeless script from a linked 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.

  • Refresh the unit to see the new values in the fields that are updated automatically: 

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

Note: 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.

Back to top

See also: