Table of contents
Overview of the self-healing feature
MagicPod has the Self-healing feature that allows the AI to automatically follow the changes and continue testing when the UI element you want to operate changes, due to design changes or similar. If you know that the UI elements have been changed in advance, you can re-upload the screen capture on In case there is a correction to the tested screen page, but it is not realistic to assume that you will grasp all of the changes before running the test each time.
Let us look at an actual case. For example, the button shown in figure 1 was originally named Register, but was renamed to Sign up. Although it depends on the implementation of the app, if the only thing that identified this button was the button string, the test would fail as is.
Figure 1. Change the button name.
When you actually run the test, and perform self-healing in relation to the button UI element, the execution test result status will change to the orange Unresolved.
Figure 2. Batch run test results.
When you click the link and open the test results detail screen, the self-healed content shall be displayed. As it was healed in step 3, and the test did not stop here, and the next steps were run without issue.
Figure 3. Test results details screen.
Furthermore, if you click the Unresolved message or the orange frame in the list of captures, a pop-up window will appear showing the details of the healing.
Figure 4. Self-healing results detail pop-up window.
In this state, the self-healing result is only a proposal and the original UI elements have not been changed.
Check the results, and click Accept if there are no problems. If you do this, the test result status will change to Succeeded and the UI elements and capture screens used in the test case shall be replaced with the new ones.
Figure 5. After accepting the results of self-healing.
If the changes do not match the actual UI, click Reject. The test result will change to Failed and no changes will be made to the UI elements.
Points to note
- Currently, the self-healing feature is only enabled for tests that are run as a batch. Note that this will not work when running a single test from the test case edit screen.
- The self-healing feature is a feature that provides assistance when an element cannot be found, and does not work if the result of a command to a confirm a found element or screen results in a failure.
- "Assertion that the value of the UI element XX matches the value to register" → The test will fail if the value is registered.
- “Assertion that the title matches MagicPod” → If the title is MAGICPOD, the test will fail.
- The self-healing feature will not work when the condition branching is based on whether an element exists or not, or when the result of an element is expected to be does not exist.
|Command does not operate
<In case the condition branching is based on whether an element exists or not>
In case the UI element exists
In case the UI element does not exist
In case the UI element is displayed
In case the UI element is hidden
<In case the result of an element is expected to be “does not exist”>
Check that the UI element does not exist
Wait until the UI element no longer exists
Confirm whether the UI element is hiddenWait until the UI element is hidden
|Commands to operate
Confirm whether the UI element exists
Wait until the UI element exists
Check that the UI element is displayed
Wait until the UI element is displayed(and many other commands)
If the UI targeted for automatic repair in test case A is also used in another subsequent test case B, the new UI will be used when test case B is executed. If there are UI elements present in the old UI but not in the new UI, the auto-repair will be automatically rejected because Test Case B will fail to find the UI elements even if the subsequent steps of test case A are successful.
There are two workarounds
1. if there is a UI where both UI element a of test case A and UI element b of test case B exist, replace the shared UI.
2. stop sharing the UI between the target test cases and change them to use their own UI.
In both cases, the locator of UI element a has changed since the previous capture, so it is necessary to re-capture it.
Then, replace the part of the test case that uses UI element a with the element on the newly captured UI.
More detailed logs can be found in the "Show detail log" in the auto-repair approval modal.
If the test case in which the self-healing occurs fails in a later step, the self-healing will be considered to have been mistaken, and the self-healing results will be automatically rejected. In practice, however, there may be cases where the success or failure of a healing result has nothing to do with the subsequent test failure, and you want to approve the healing result. In such a case, more warnings may be displayed compared to normal repair results, but you can still approve these by pressing the Force accept button.