This week I went to the “Mobile Automation With Appium” workshop hosted at this year’s Selenium Conference in London.
For our mobile offerings, we here at Caplin are able to use a combination of Selenium, Serenity and utilising various device modes with Chrome, to fulfill most of our automated testing needs. In the past we have trialed Appium, however owing to problems encountered during these trials we did not have enough faith in the framework and its dependencies to implement it as part of our builds.
My objective on visiting the workshop was to see whether the hurdles we struggled to get over on previous attempts had been alleviated and whether we can benefit from some of latest features available.
Appium
The best of way of thinking of Appium is “Selenium for mobile”. It is an open source cross platform tool allowing users to run automated tests on mobile devices and emulators. The workshop made use of Appium and Ruby for tooling and to write the tests.
Before arriving at the workshop we had a long list of dependencies to download and install, which was no picnic owing to problems mostly with some troublesome RubyGems.
The agenda of the workshop included: getting the Appium IDE running, utilising the Inspector to assist in finding locators, writing and refactoring spec tests, using ARC to try out test commands and interact with the app on the CLI, using gestures, generating reports with screenshots using Allure, running tests on multiple emulators concurrently.
Pros:
- ARC – being able to run test lines and try out waits on the CLI without having to run entire tests are a great boost to the test writing process.
- Gestures – mimicking gestures with readable api calls using Appium::TouchAction are simple to use and a huge improvement on our current testing frameworks.
- Parallel running – using Rake (Make for Ruby) it was possible to run tests on multiple devices in parallel, along with tools such as Selenium grid this should aid in reducing build times.
Cons:
- The dependency issues were clear given the number of developers who arrived at the workshop with varying issues not specific to a single OS, in some cases the online documentation was limited. This was also the case when we ran into issues with attaching test output to reports – googling the errors returned next to zero results.
- The time it takes to launch a device or emulator can be slow.
While some of the features tried out were polished and worked out of the box, others ran into issues which could not always be solved with a quick google. Getting developers to write tests can be an uphill struggle at the best of times, so it’s critical to pick a testing framework with minimal headaches.
Appium has without a doubt come a long way since Caplin originally tried it out in previous years. The tools used in the workshop showed that there are great benefits at every stage of the automation process; from ease of writing tests to making suites robust and readable as well as generating quality reports. Caplin would love to take advantage of these benefits, but the first step will be to see if we can overcome some of the hurdles exhibited during the workshop and create a boilerplate that will be stable across all OSs.