Test Generation
Recorded playback files & Automated Runs can be transformed into Unity Test Framework tests automatically with the click of a button. A simple test can be generated, which creates a C# test that points to recording file or recording asset, and invokes it in the same manner as a local editor-based run. Playback files can also be converted into a "full" test script where every distinct action taken is a separate line of code. This allows for extensive customization and enhancement of automatically-generated tests.
Test Generation Window
Located in the Automated QA Hub (from the menu bar: Automated QA > Automated QA Hub > Test Generation
), this window displays a list of json recording files than can be used to generate tests from.
Recordings that correspond to existing generated tests with edits will prompt a option to overwrite the previously generated tests.
An option for "Use Simplified Driver Code" is checked by default. This will generate readable and lightweight C# tests. It utilizes the Driver class and PageObjects.
Deselecting this checkbox will generate C# code that utilizes Step Files and is less human readable, more customizable, and nearly identical to the original json recording (Utilizes all TouchData properties such as timeDelta, which is the time between each action).
The two types of tests that can be generated are Simple Tests & Full Tests.
Simple Test
Consists of a C# script and test with a reference to an associated recording. There is minimal room for customization of the test, as every step performed by the recording is still contained in the referenced recording file, rather than being executed by C# code in the generated test.
Full Test (Recommended)
Consists of a test script and "Step" file(s). Every recording and child segment(s) of a recording selected for test generation will have the actions it performs converted into a line of C# code. References to each of these actions is stored as a TouchData object in a Step file, and each Step file is associated with the recording or segment that defined its TouchActions. This more detailed script allows for significant customization, including adding assertions or logic before and after each action performed, or adding additional actions to perform, along with easy access and modification of the underlying TouchAction data that defines performed actions.
Automated Runs that contain a "RecordedPlaybackAutomator" will have the associated recording file broken down into individual steps in the same way that a Full test is generated directly from a recording file.
Page Objects
These classes are a repository for properties that identify a GameObject in a scene. The properties are query strings which are identifiers that uniquely reference a predictable and consistent list (or single instance) of GameObject(s).
With a single reference to a locator string, the locator strategy can easily be update in just one place without having to update the locator in every single test that searches for this/these GameObject(s).
This file is automatically generated when converting a recording or automated run into a C# script. You may update the values of the properties, and add anything to the file. However, modifying the property name and class name will disconnect the relationship between future automatically-created PageObject properties and existing properties. This relationship prevents multiple locator references to what is intended to be the same GameObject(s) when new tests are generated.
Step Files
These classes contain references to a TouchData objects used in recordings. They are essentially the C# version of each step stored in a recording json file.
Additional Options
By default, the Use Simplified Driver Code option will be checked. This will change the logic used in code generation. The result is much less code needed to perform identical actions.
As an example, without the "simplified code" option selected, a single button press would generate the following code: 1) A step file with TouchData for the action, which stores metadata about a recorded action. 2) Code in test SetUp to register the action. 3) A line of code to perform a MouseDown event on the button. 4) A line of code to perform a MouseUp event on the button.
With the "simplified code" option selected, a single button press would generated just one line of code in the test file:
yield return Driver.Perform.Click(Scene_HomeScreen.Clickable_StartButton);