Everybody Tests

In 2013 at a Google-hosted event in New York called the " Google Test Automation Conference ", or GTAC for short, a team of Google engineers tried to sell the attendees the idea that a device lab consisting of real world devices is not as maintainable or optimal of a test bed as a vast server farm running emulators. That's right. Google said that in order to avoid the tyranny of dealing with the real world everyone should have a Google-scale server farm for testing their apps ( video , slides ). And then 2 months later they bought Appurify . Those are pretty epic mixed signals. Example of less paradoxical signaling. Now don't get me wrong, I would LOVE to have Google's server resources for my automated testing. But like many companies who do not make mobile apps or even software in general as their primary business, my current employer seems to prefer to invest more shall we say "modestly" in their app test automation environment resources. ...

In this admittedly niche topic of software quality assurance, I'm impressed at the traffic this tiny little blog has received. I'm thankful for the feedback so far and nothing speaks more loudly than the popularity of the few posts I've made on the topic of UIAutomator. They are by far the biggest sources of traffic. In order to help serve the common good of other QAEs working in Android, I'd be happy to explore the topic more deeply so I'm going to start a list of a few subtopics worth digging into. WebViews - this is a common area of concern for many people, especially on projects with low budgets for native app development. Whether WebViews can ever be supported or to what extent that can be supported by UIAutomator.jar is a topic that should get regular treatment. Useful UiWatchers - because these handle asynchronous events it would be useful to generate a library of common interface event Watchers that tests should be able to use in a generic fashion. It w...

"Education is the key to unlock the golden door of freedom." ~George Washington Carver  The successful creation and management of a device lab at my company has required many hours of work from an autodidactic polymath. Unfortunately that responsibility fell to rest on me instead (with an audible *THUMP*). This is another piece of the narrative of my education. Waking and Unlocking Jelly Bean Devices Automatically One of the common traits to all Android devices we use in house is that they're all provisioned with a Google Apps account for remote management purposes. This includes "personal" devices (BYOD is alive and well) and lab devices. Under the auspices of Google's MDM scheme , there is no concept of segregating collections of devices and applying rules regarding PIN strength, screen timeouts, etc (at least according the the domain admin whose words I have no need to distrust). This is frustrating to me since my first experience with MDM was bac...

"I'm looking over your shoulder... only because I've got your back." ~ Stephen Colbert After my recent UiAutomator review a user brought up an important question about the use of UiWatcher. The watchers serve as async guardians of the test flow, making sure the odd dialog window doesn't completely frustrate your tests. Having a tool that automatically watches your back when you're focused on the functional flow of your tests is awesome. 100% pure awesomesauce. Since the API documentation on watchers is scant and the UI Testing tutorial on the Android dev guide doesn't cover their use in depth, I figured I should add a post here that goes over a simple scenario demonstrating how to use this fundamentally important UI automation tool. In my example code below, I'm using uiautomator to launch the API Demo app (meaning run this against an Emulator built in API level 17 - I used the Galaxy Nexus image included in the latest ADT and platform tools). ...