Appium Test Synchronization

Frank Moyer

Reading Time : 5min read
Appium-Test-Synchronization.tiny

As we’ve gone through various Appium tutorials, today we’re touching on Appium synchronization, where we’ll understand how wait (or Synchronization) performs a vital role in Automation. This will test if two or more components are working together in parallel at the same pace or rate. We call it synchronization.

In almost every application, whenever the screen changes, it takes a few milliseconds (or seconds) to load, and if you do not manage the proper synchronization in your code then you might face “ElementNotVisibleException” or “NoSuchElementException” exceptions. This is because the screen hasn’t finished loading and is not synchronized with your test code. To avoid this, we need to implement proper synchronization in our automation script.

We can categorize synchronization in two types:

  1. Unconditional,
  2. Conditional.

Now, let’s discuss each of them.

  1. 1. Unconditional Synchronization:
    • Unconditional Synchronization in Appium is also known as Static Synchronization or Static Wait. As per the name, it specifies a particular fixed (static) time to wait before starting the execution. Here, Appium (or any program) will wait the specified amount of time and then it will resume the execution.
    • The standard example of Unconditional Synchronization in Appium is below:
try {
	Thread.sleep(1000);
} catch (InterruptedException e) {
	e.printStackTrace();
}
    • Here, the Thread.sleep(1000) function would take 1000 ms to execute.
    • One key to note is that this wait will be absolute, even if the underlying condition you were waiting on has been met. For example, you may put in a wait for 3 seconds waiting for the screen to load. Even if that screen loads in 2 seconds, the system will still wait for the additional second. The converse is also true. Sometimes the wait finishes before the underlying operation and execution proceeds. In test automation, for example, limited network connectivity may slow the mobile application response time. A screen change may also now take 5 seconds, while the script only waits 3 seconds. Once again, you’ll face “ElementNotVisibleException” or “NoSuchElementException” exceptions.
    • So unconditional synchronization in Appium or static wait is not the preferred way to deal with dynamic responses.
    • However, it is a viable strategy to use it when you are working with some 3rd party interfaces. Also, in the case where you cannot identify the underlying condition, so you’ll need to wait on OR you’re sure about the response time.

Which types of Wait you should use When?

Wait TypePurpose
ImplicitWhen you need to apply common wait without any condition.
ExplicitWhen you need to test expected condition for an element.
FluentWhen you need to test expected condition for an element after specific amount of time like every x seconds/minutes.

Synchronization in Automation Framework (WaitUtils.java)

  • In Chapter-7, we defined the Wait Utility in order to handle synchronization in our tests. In this section we will look into the usage of it.
  • We have created the WaitUtils object at 2 places to leverage the synchronization at Page Object or Test Class level:
  1. BasePO.java

Figure-1: WaitUtils object in BasePO

  1. BaseTest.java

Figure-2: WaitUtils object in BaseTest.

  • You can see there are many wait methods(of Implicit and Explicit wait) are defined in WaitUtils.java file, Now let’s create a simple example to use WaitUtils using the WaitUtils object at the Page Object and Test Class level.
  • WaitUtils.java
    public class WaitUtils { ……. ……. public void staticWait(final long millis) { try { TimeUnit.MILLISECONDS.sleep(millis); } catch (final InterruptedException e) { } } ……. ……. }
  1. WaitUtils usage on TestCases.javaHere the script is using staticWait(long milliSeconds) method, so after tapping on Login Screen Text View,the script will pause the execution for 2 seconds.
    public class TestCases extends BaseTest{ @Test public void test() { HomeScreenPO homeScreenPO = new HomeScreenPO(driver); homeScreenPO.tapOnLoginScreenTextView(); waitUtils.staticWait(2000); } ……. ……. }
  2. WaitUtils usage on .java
    Here the script is using the same staticWait(long milliSeconds) method of WaitUtils.java class. In HomeScreenPO.java we have defined tapOnLoginScreenTextView() method which clicks on Login TextView – after tapping on Login Screen Text View, execution would pause for 2 seconds.public class HomeScreenPO extends BasePO { ……. ……. /** * This method will click on Login Screen textview. */ public void tapOnLoginScreenTextView(){ loginScreenTextView.click(); waitUtils.staticWait(3000); } ……. ……. } So both of them doing the same work but at different places!Many beginner Appium developers sometimes wonder when to wait and for how long. Using wait in your scripts will become intuitive the more you use them and the more you run into certain conditions. And don’t worry, you’ll be greeted with exceptions when you forget to include the proper wait!

Interested in Learning More?

Subscribe today to stay informed and get regular updates from Kobiton

Ready to accelerate delivery of
your mobile apps?

Request a Demo