Appium, Robotium and Espresso improvements!

Last week brought some very interesting updates, improvements and fixes to our platform! We have exciting news regarding Appium capability and a new feature as well as new features for Espresso and Robotium. We’ve been also asked by our users to implement some tweaks for automated testing and we have decided to make those users happy. But that’s not all that’s new!

Appium new features and improvements

Appium becomes faster with device caching

The most exciting feature this week is a new capability for Appium — “testobject_cache_device” — which allows users to use the same device for their upcoming tests. That means that there is no device opening time and no installation time for the 2nd, 3rd,…. appium tests, speeding up your testing process even more. Here are some numbers for you:

Test Type Old Factor New Factor Appium Android Native Test 3.5 1.5 Appium iOS Native Test 3.5 1.5 Appium Android Web Test 3.0 1.4 Appium Web Test 6.0 2.0

In the first column are the Appium test types; in the second column is how much time Appium test runs in the cloud were taking compared to running the test locally; in the third column you can see how much the testing time it improved. The more tests you run the faster testing gets! (e.g. Appium Android Native Test was taking 3.5 times more time than it would take if run locally. Now that time is reduced to just 1.5 times compared to running the test locally.)

Appium adjusted timeout

We also have also news about a new feature: Appium command timeout. Appium command timeout determines how long Appium will wait for a new command from the client before assuming the client quit, ending the session. The time is usually set to 60 seconds; we have now set it to 90 seconds.

Test reports

We managed to make the test reports URLs shorter with just essential information, allowing you to have a clearer overview of the executed test: https://app.testobject.com/someuser/appium/executions/1

Robotium/ Espresso improvements

Robotium/ Espresso fail when device is not available

How it worked before: the test would try 3 times to execute on a device before marking it as failed in a test suite if a device was not available. The main problem was that Gradle plugin would not report this as test failures.
 If a device in your test suite is unavailable during your test run, the Gradle plugin will fail and you won’t get wrong data. That’s one big update on our platform and you can set this configuration in the Gradle Plugin. Find the detailed description here.

Manual testing improvement

We have noticed that during some manual tests session, the log would become very long, using too many resources and the browser would become accordingly impossibly slow, because it cannot elaborate that many elements. We have now fixed this problem by limiting what is shown: you will now see only short pieces of the log and if you need to see more, you can just request to load more log pieces.

There will be exciting speedups for Android next week, so be prepared to take your Android testing to a whole new level!

Happy Testing!

The post Save Time with Appium, Robotium & Espresso improvements! appeared first on TestObject.

from
http://redirect.viglink.com?u=https%3A%2F%2Ftestobject.com%2Fblog%2F2016%2F08%2Fappium-robotium-espresso-improvements.html&key=ddaed8f51db7bb1330a6f6de768a69b8

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.