Here, we will explain how to shorten the run time for tests.
1. Common to Mobile apps/browsers
- Changing the wait command If there are many cases where the "wait for seconds" command waits for a prolonged period of time, change the command to one that “waits until the UI element is present” 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.
- Parallel execution If there are no dependencies between tests, use label and browser pattern/device pattern are used together, and run the tests in parallel.
2. Mobile app only
- 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.
- 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.