Appium Tip #10: Making Tests Fail Faster/Slower and Catch Errors

Everything About Appium Test Automation

This is the tenth tip on our massive 37 Things You Should Know About Appium blog series. This time around we’ll focus on catching errors – on pace you want those errors and fails to happen. Sometimes it can be beneficial to make your test fail – for whatever reason – faster. If there are obvious issues with the test, it’s better to make test fail as fast as possible and fix those issues for the next test run.

tip#10-thumbnail

How to Use newCommandTimeout

The newCommandTimeout is a handy desired capability function for managing how long Appium will wait for a new command from the client before assuming that client has quit and the session will be terminated. By default (and as not being set) newCommandTimeout is 60 seconds, and it can be set using the following capability (with Java code line example):

capabilities.setCapability("newCommandTimeout", 120);

Furthermore, the newCommandTimeout can be adjusted throughout the test script to make the script fail faster or slower depending on the situation. This is a very useful command also when developing a script locally, since it lets your script fail faster instead of forcing you to wait for the default 60 seconds before reporting about missing elements expected by the script.

Catching Errors & Making Tests Fail Faster with newCommandTimeout

What I usually like to do is set the newCommandTimeout to around 10 seconds when testing locally, since that should definitely be long enough for an online app to download and display all content in most situations. For client-side Cloud execution I like to go for at least 60 seconds timeout, since the connection speeds fluctuate more often and shouldn’t be trusted to be fast 100% of the time. Also, there are typically lots of data passing between the client and server and it’s recommended to keep newCommandTimeout higher. In addition, some slower device models used via cloud also download and display content slower than the high-end devices I use to develop my tests on, which is easy to forget when perfecting a script locally.

Appium Recommendation for Testing, Tips and Tricks

There are situations where you want to try to find an element or execute a command, but the test flow isn’t completely dependent on it to happen. Using hide_keyboard() command is a common example with Appium, as the soft keyboard of mobile devices tend to act a bit differently depending on OS versions and device models (take a look of an example here). This command you will want to enclose to try-catch block, since it will cause a WebDriverException every time you try to use it while the keyboard isn’t visible.

Similar situation to hide_keyboard() could be a pop-up in the tested app, which you won’t be seeing 100% of the time depending on the tested device or some other criteria. One way to deal with this is to create a logic around your test script to check for pre-defined blocking elements whenever your test isn’t able to progress and then try to progress again. This could even be a list of more than one blocking elements, if the tested app happens to include various interruptors to your test flow. The newCommandTimeout could be very handy in these type of checks.

New Appium Tips Coming in This Appium Blog Series!

We’ll continue with a bonus topic next week, so stay tuned – and also let us know what you think and what are those topics you need more information about. Happy Appium Testing!

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close