Appium Test Synchronization

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

In our ongoing exploration of Appium through comprehensive tutorials, today we’re diving into the crucial aspect of Appium synchronization. Specifically, the significance of wait mechanisms, often referred to as Synchronization, in the realm of Automation Testing. Our focus will be on evaluating the seamless collaboration and concurrent functioning of multiple components at a consistent pace, a process called synchronization. Join us as we unravel the intricacies of this vital feature in Appium’s toolbox.

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. 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. There may be 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)

  • We have created the WaitUtils object at 2 places to leverage the synchronization at Page Object or Test Class level:
  1. BasePO.java
image of code
Figure-1: WaitUtils object in BasePO

  1. BaseTest.java
Image of Java code
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.java
    Here 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 are 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! Don’t forget to check out our Appium tips and tricks that can be handy along the way too.

Appium eBook

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