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