Over the past few years, Appium has gained tremendous popularity due to its support of many languages and multi-platform automation possibilities. It is the most popular tool for test automation engineers as of today.
However, there are times when beginner Appium users have a curiosity about how it works under the surface. Some intermediate/advanced users always wonder how to debug their automation code in conjunction with the Appium source code to find out why that element on UI can’t be located or why the click is not working on that custom element.
In this workshop, we will start with the tools that are building a block of higher-level android automation frameworks such as espresso, uiautomator2, etc. Later, we will deep dive into Appium with espressodriver.

So you have got a few UI tests and they are running in parallel, great! However, life will not be so sweet once these 'a few' turns into 'a lot'. We grew from a few to 1500 UI tests (although not particularly proud of this number, there are situations and reasons)

We started with a simple parallel distribution of tests 3 years ago. As test count increased failure count run time increased along with increased flaky tests. Mobile tests had their own challenges (eg. device dropping-off, random wi-fi issues, etc) To keep up with this, we created a queue and workers based solution which could distribute the tests more efficiently (https://github.com/badoo/parallel_cucumber). Over time, we made more improvements, in particular:

• Segregation of failures based on infrastructure issues and re-queue the tests
• If a device/emulator malfunction, rescue the tests to another device
• Repeating a single test on 100s of the worker in parallel to detect flakiness
• Repeat a test if a known network issue
• Terminating the build early if more than a certain number of tests have failed
• Health check of each device, before each test to ensure reliability
• Muting a test if failure is known, and highlight outdated mutes if the related task is fixed

In this talk, I will talk about the initial challenges with running UI tests in parallel (Selenium and Appium), how we approached the queue based solution and continuous improvement of this solution; finally, how attendees can use it at their workplace or create their own solution based on our learnings.

Have you been in a situation when some cases are impossible to test because Appium doesn't have support? Appium is improving continuously and release of espresso-driver is an example of this.
Espresso driver opens up possibilities of white-box testing using Appium. One of which is the ability to call platform methods on elements via backdoor without modifying Application under test. What it means is, if the Android platform supports some actions or properties on an element, then Appium will support it out of the box.
For an automation engineer, that's a very powerful addition. I was fortunate enough to work on this feature and would like to showcase what are the various tricky cases where this feature can be applied. There will be real examples shown with a sample android app. I will also introduce one more small bonus feature at the end, about flashing elements on screen ;)

Application Backdoor via Appium

There's a shift towards open-source mobile test automation tools happening today among developers and QAs. Whether it be Appium, Calabash or anything else: all are good, with some major limitations.

While a chosen tool may work well when you first start using it, things can quickly get out of hand with changing business requirements. We started using Calabash at Badoo when there was no Appium. Given the capability of Appium to drive the whole device, we started automation of new apps with Appium. However, we realized a powerful feature was missing in Appium for Android! : The ability to call Application code from automation code like Calabash Backdoors.

As Appium UiAutomator server is based on instrumentation, we modified it such that we could instrument our app under test. This gave us the power to access context of Application under test and invoke public methods of Activity using reflection APIs. We use these methods to setup app state, seed DB OR even enable/disable some client-side A/B tests. This makes our application more testable and our tests more predictable.

This talk is going to be about how I achieved the above solution and benefits of backdoors.

There will be a small demo and code!

This talk is about a ruby gem I wrote for adding visual assertion with selenium as driver.

While we continuously implement new functionalities in our app, automated functional tests acts as safety net and gives us confidence. Still, there is something missing. Many times we get feedback like:
"Sign-In button has shifted and user have to scroll down to see it"
"We wanted to change background color of screen-X, it got changed for Screen-Y screen as well"
"Why has fonts of this link become so tiny?”
I am working on customer facing enterprise level Mobile apps of one of the biggest airline in the world. For us user experience is as important as functionality.
Our regression suit did not have capability to catch such issues. Moreover, we started building another airline app from the same codebase with only change in user interface of this new app. This means, change done for one app, affects another. Hence, it became really critical to enhance our automation with visual assertions.
To accomplish this, I worte my own gem called 'nakal'.http://rubygems.org/gems/nakal

This is going to be a Talk + Demonstration

While we continuously implement new functionalities in our mobile app, automated functional tests acts as safety net and gives us confidance. Still, there is something missing. Many times we get feedbacks from clients like:
"Sign-In button has shifted a bit and user have to scroll down to see it"
"We asked to change background color of screen-X, it got changed for Screen-Y screen as well"
"Why has fonts of this link become so tiny?”
I am working on customer facing enterprise level Mobile apps of one of the biggest airline in the world. For us user experience is as important as functionality.
Our regression suit did not have capability to catch such issues. Moreover, we started building another airline app from the same codebase with only change in user interface of this new app. This means, change done for one app, affects another. Hence, it became really critical to enhance our automation with visual assertions.
There are many tools which can do this, but they charge hefty money and also does not give full flexibility. Therefore, I worte my own gem called 'nakal'.http://rubygems.org/gems/nakal