Appium Tip #12: Useful Timeout Capabilities and Commands

This is the 12th tip in our Things You Should Know About Appium blog series. This blog will touch on useful Appium / Selenium timeout capabilities and commands.

Typically, timeouts occur when certain elements during the testing become inactive, unresponsive or something else goes ‘wrong’ in the test or app itself. Timeouts are also useful for handling test execution, set frequency to wait for certain events to happen, or scale the use of multiple devices simultaneously. However, timeouts consume time if used excessively. In this blog, we’ll take a look at one great tip that gets your tests executed – and timed out – in a timely manner.

The mobile test automation – and generally automated testing – is all about handling timeouts in a logical, but efficient fashion. As said, timeouts are used to make sure your tests don’t take hours and hours of time while ending up with no results, because the test couldn’t actually go forward after the first few steps. This is why our mobile app testing platform also has its own high-level timeouts for test runs. To start Appium mobile testing, you need a proper Appium environment. Download our free Appium beginner’s guide to learn how to set it up.

Appium Timeout Desired Capability on Bitbar

The default suggested timeout for a test run on Bitbar Testing is 10 minutes, which can be adjusted according to your personal needs up to 60 minutes. To adjust this timeout with the client-side Appium, you’ll need to familiarize yourself with a new capability and use it in your scrips – testdroid_testTimeout. The description of the desired capability is as follows:

Testdroid Desired Capability: testdroid_testTimeout
Mandatory: no
Description: The timeout for whole test execution (in seconds). It's configurable only, if you have active plan/subscription.
Default: 600 (seconds)
Example:
...

capabilities.SetCapability("testdroid_testTimeout", 1200);

This timeout will take effect by ending the execution process in any case when the time limit is met. The benefit of having this kind of a hard limit to test run duration is, of course, to protect our customers from ending up spending all their device time on an unexpected behavior by the device.

TIP! If you do have a set of tests that take longer than 60 minutes, it’s a good idea to arrange them to smaller sets and execute side-by-side. We do have multiple copies of the most popular mobile devices, so launching multiple tests simultaneously will most likely shrink the time spent waiting for those results to be ready! Using a device_finder script to choose the device for execution is a perfect fit here.

Implicit Wait with Appium

Implicit Wait tells Appium how long to keep looking for an element on the app’s screen before deciding it’s not there. Setting implicit wait value is an easy and efficient way to make sure your tests fail fast enough in an unexpected situation.

The default value for the implicit wait is 0, and some people suggest keeping it that way. When you keep it at 0, however, the Webdriver will keep looking for the defined element until any other timeouts come around. When it comes to cloud execution, this may end up eating up your device time faster than it needs to.

We usually like to set this timeout to anywhere between 15 and 60 seconds. This will make sure that slow internet connection or device’s test execution speed isn’t the reason for failure, but also makes sure your test doesn’t just hang until some other timeout comes around. Appium server’s newCommandTimeout capability with its default value of 60 seconds is usually the next timeout to fire up if communication between the client and server for some reason stop.

But what if you want to expect an even faster or slower fail at some specific step? Easy: set the new timeout before the step in question and re-set it right after to continue with your default value from thereon.

Java: 
driver.manage().timeouts().implicitlyWait(60);
Python:
driver.implicitly_wait(60)
Ruby:
driver.manage.timeouts.implicit_wait = 60
C#:
driver.manage().Timeouts().ImplicitlyWait(Timespan.FromSeconds(60));

Explicit Wait with Appium

Explicit Wait is a wait timeout explicitly chosen for a specific command. This brings more complexity to scriptwriting, but it may be a good fit depending on your scripting style. As mentioned in the Selenium Webdriver’s webpage, mixing up active implicit wait with explicit waits may cause unexpected behavior, such as summing those waits together for even longer wait.

The same page also describes how to set explicit waits with different languages. If you end up using explicit waits a lot, writing a convenience method to deal with the complexity is surely a good way to go.

Timeout for Appium Sleep

Sleep is regarded as an explicit wait command which emulates a requirement of waiting set amount of time before proceeding. It’s a defined amount of time to wait that will always happen, no matter what.

To set a sleep simply:

Java:
Thread.sleep(5);
Python: 
sleep(5)
Ruby: 
sleep(5)
C#: 
Thread.Sleep(5);

Cool, these are just a few ways to add timeouts in your test scripts and have your tests running in a timely manner. We’ll continue with you new tips next week, so stay tuned and keep testing! See you next week!