This is the tenth tip on our massive Things You Should Know About Appium blog series. This time around we’ll focus on catching errors – on the pace you want those errors and fails to happen. Sometimes it can be beneficial to make your Appium tests fail – for whatever reason – faster. If there are obvious issues with the test, it’s better to make tests fail as fast as possible and fix those issues for the next test run.
How to Use newCommandTimeout
newCommandTimeout is a handy desired capability function for managing how long Appium will wait for a new command from the client before assuming that the 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):
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 Appium tests 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 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 tends 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.
A similar situation as
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 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 interrupters to your test flow. The
newCommandTimeout could be very handy in these type of checks.