Here, we will explain how to shorten the run time for tests.
Table of contents
- Common to Mobile apps/browsers
- Mobile app only
1. Common to Mobile apps/browsers
1-1. Changing the wait command
If there are many cases where the Wait for fixed seconds command waits for a prolonged period of time, change the command to one that Wait until UI element exists or other such conditions. *Command list
Initialize only when necessary, such as “Log in if you are not logged in” and “Delete any existing data” (note that this may increase dependencies between tests).
Do not perform pre- and post-processing that is not directly related to what you want to verify, such as deleting existing data, from the screen. Instead, a Web API for testing should be prepared on the server side and used there. The maintainability is also increased.
1-3. Parallel run
If there are no dependencies between tests, use label and browser pattern/device pattern are used together, and run the tests in parallel.
1. Create labels
Go to the Settings tab on the project page > the Test case labels page, and click Add.
Enter any name you like and click Create.
2. Assign labels to test cases
Open the Info tab for the test case you wish to assign, check the appropriate label, and click Update.
You can see the labels assigned on the test case list page.
3. Edit batch run settings
In an existing or new batch run setting, click Add to add a pattern.
Click Setup in the Test case labels field on the Advanced settings tab.
On the one hand, drag and drop the test case label Daily run (Flow A) into Includes.
Set the other one to include Daily run (Flow B) as well.
Then, click Common settings and switch to Parallel run in Running method. The standard plan allows two parallel runs at the same time, but by adding options, up to 10 parallel runs are possible.
Reference: How to increase test cases and projects
Instead of labels, test case numbers can also be specified, and the order in which test cases are executed can also be specified.
2. Mobile app only
2-1. Changing the locator
It is better to use the accessibility id or ios class chain locator wherever possible, as the xpath locator tends to be slow (as in the case of the standard locator proposed by MagicPod).
Referring to Assigning the accessibility id (iOS), apply the identifier to as many elements as possible on the app side, to enable the accessibility id locator to be used on MagicPod. If the accessibility id cannot be used, you will be forced to use the slower xpath, etc.
2-2. Reducing the number of elements
The speed at which tested elements can be searched is generally proportionate to the number of elements that exist in the UI tree (even if the elements are hidden, the fact that they exist in the tree will slow down the process.) You may be able to improve the run speed of the tests by implementing the app in a creative manner in order to ensure that unnecessary elements are not generated, and that there are not a lot of items or dummy elements hidden in the background.