Skip to main content


Showing posts from 2012

UiAutomator and Watchers: Adding Async Robustness to UI Automation

"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). The te…

UIAutomator Redux: WebViews still opaque

Last time I wrote a quick review of Android's new UIAutomator tool. In that review I tried to cover it as a comparison between Android's JUnit and MonkeyRunner tools which it seems to be designed to bridge. One area I left out of my review was whether it provides deep access within a webView. This question was brought up by a Google+ user in the Android Developers' post notifying us all of the release of these new tools and I figured it deserved some investigation.

My expectation was that WebViews would remain opaque to the tool since its construction of the XML of a given view hierarchy seems like an extension of Hierarchy Viewer and thus shared its limitations. My experiment was to use the Netflix app since it is a well known app and is built making very heavy use of Android's WebView. Netflix does this so that they can deliver updates to devices through a single app rather than customizing their apps for multiple screen sizes. When I first bought my Samsung Galaxy N…

UiAutomator.jar: What happened when Android's JUnit and MonkeyRunner got drunk and hooked up

"Drunkenness does not create vice; it merely brings it into view" ~Seneca
So Jelly Bean 4.2 landed with much fanfare and tucked in amongst the neat new OS and SDK features (hello, multi-user tablets!) was this little gem for testers: UiAutomator.jar. I have it on good authority that it snuck in amongst the updates in the preview tools and OS updates sometime around 4.1 with r3 of the platform. As a code-monkey of a tester, I was intrigued. One of the best ways Google can support developers struggling with platform fragmentation is to make their OS more testable so I hold high hopes with every release to see effort spent in that area. I have spent a couple days testing out the new UiAutomator API and the best way I can think of describing it is that Android's JUnit and MonkeyRunner got drunk and had a code baby. Let me explain what I mean before that phrase sinks down into "mental image" territory.

JUnit, for all its power and access to every interface, every s…

Thinking, Boxes, and Perspectives

A farmer had a plot of land he wanted fenced in and a limited budget for fence materials. He asked his three friends, an engineer, a physicist, and a mathematician, to propose solutions. The engineer being the practical sort took the full budget and bought the largest amount of fence and laid out the fence in a circle. Happy with his practical solution, he said, "friend, that's the biggest area enclosable with your budget." The physicist scoffed at the engineer's lack of "thinking outside the box" and laid out the fence in a straight line saying, "I presume the fence to extend infinitely in each direction. There, I've fenced half the world." The mathematician calmly took a 5-foot section of fence and built a circle around himself. Once encircled, he proudly announced, "I declare myself to be on the OUTSIDE."
~ Nerdy joke I heard somewhere. A local shipping company has a slogan on one of its trucks that made me laugh out loud inside m…

Daniel Pink says we're doing it wrong

Daniel Pink claims science says we're doing it wrong in the Deloitte Digital studio model.

Currently within my office there is a formalized effort to find ways to improve our work culture. According to Pink, the organization needs to learn to support and reward the correct set of motivations. Based on his talk, one of the friction areas I see between studio consulting and financial consulting is that the bonus structure for financial consulting where mere effort and extra time linearly deliver incrementally better results works against you in the creative software and design work we do in the studios. Pink suggests if we want to adapt to what the decades of motivation research conclude, maybe we should talk about removing the consideration of performance-affected bonuses from the studio model entirely, just push the financial concern right off the table, and let people have the agency to act on the intrinsic motivations that made them worth…

Kickstarting Internal Projects

"Kickstarter isn’t a store — it’s a new way for creators and audiences to work together to make things." ~ Perry Chen, Yancy Strickler, and Charles Yadler - Via's blog
What the hell is an "Intrapreneur"? ~ Me. About 10 seconds before having my mind blown reading this article on
I'll just say it. I want to build a Kickstarter platform inside my company so I can work from within to change the way things get done. How about I explain why...

Last year around this time it was announced that my beloved little startup would merge into a large, multi-national conglomerate. Now those of you who have made that transition know that it comes with some benefits (stock buyout, larger resource pool, potential for job security). There are also typically some changes to how you do things. At a small startup, you typically get as much responsibility as you'd like based on willingness to drive development on products and tools that could en…

Boom! Screenshot! Capturing on-device app state when Android UI tests fail.

"A sub-feature of this is the screenshots feature. While most of the fare you will see will be OMG LOOKEY HEREs, with a little skill, you can take quite good images."
~PARDOX460, The Art of Taking Good Halo 3 Screenshots Remember back a few posts when I dropped a bit of info about maybe perhaps capturing screenshots on failed UI tests? Well it wasn't a lie and now I'm going to show you how. First, I'll go over the prerequisites. Second I'll present you with a code sample that demonstrates how to implement the screenshot tool in your tests. And finally I'll wrap up with some recommendations on further steps to embed this into your continuous integration environment and practice. Let's get started, shall we?

Phase 1: Prerequisites The bell I'm forced to ring whenever it comes to Android test automation is that Google have deigned to build it around emulators. This is convenient for them because they're not beholden to manufacturers' engagement…

Q&A #1 with the QAE

*tap tap* Is this thing on?

Okay, I have no idea when to start these kinds of things but I'd like to make a habit of being available for questions here. So here's a Q&A request. If you have any topics you'd like to see addressed, if there are any posts I've made so far that got you thinking, or if you just want to know more about me, please reply in the comments section or email me directly at:

I'll reply in a follow-up post if the topic bears broadcast and more directly if you have personal questions you'd like kept to a smaller audience. Feel free to add comments too. Don't worry about my ego, I grew up with freckles and glasses. I'm bulletproof now.

My Evil Plan to Make Everyone Eat My Dog Food

"There are professional taste testers at the dog food companies that eat dog food all day. If you can afford dry dog food, see if u can afford a box of oatmeal and half a dozen eggs for protein. You are much better off eating human food."
~in response to "Is dog food safe to eat?" via Yahoo! Answers
Imagine you're at a board meeting for a major dog food brand. Now imagine that the CEO begin the meeting by picking up a fork and cracking open a can of grey, slime-doused kibbles and taking a large, oddly enthusiastic bite. According to Wikipedia, this is the origin story for the phrase "eating your own dog food" from which the practice of dogfooding derived its name. While the image above may be literally quite unpalatable, the ideals behind it are sound in this author's humble opinion. Why ask your clients to accept something you yourself haven't vetted outside the team of those who built it?

So how do you empower a large crowd of people to tes…

Lies, Damn Lies, and Android Non-Rooted Device Code Coverage

"There are three kinds of lies: lies, damn lies, and statistics."
~Mark Twain, aka Samuel Clemens In a previous post I mentioned rather blithely that we were collecting code coverage data from live devices using Emma. If you're unfamiliar with Android's use of Emma, which comes with the Android SDK tools when you install them, the documentation won't do you much good. It isn't to say that the Android developer portals' "Testing from Other IDEs" section isn't helpful or that the online documentation for the SDK's InstrumentationTestRunner isn't either. Far from it. But if that's all you read, you may find yourself getting confused shortly after getting started.

Let's say for example, that you begin your deployment of code coverage tracking via the robust set of Ant commands included in the default build.xml. You may notice from the Testing from Other IDEs section above that there is a simple command you can run that allows yo…

Deploying Android Automation in Parallel

So here we go, right off the deep end.

One of the things that has bugged me about Android since I first started with it 18 months ago is the half-complete features and tools supporting on-device automation at any kind of enterprise scale (as opposed to just a few developers and devices in some garage somewhere). So much of the platform just integrates so beautifully with other scalable components of a build and test system that it felt like a hack when we managed to get parallelization up and running in our device lab. Hey, at least the platform is open and flexible enough to do so in the first place, right? A startup in Portland is currently building their business model off this functionality (holla, AppThwack, go on with your bad selves!).

So it is there for the clever. I just wish it didn't take being clever to manage running and monitoring multiple, simultaneous jobs on actual, live devices. Why? Well because my cleverness is not nearly as strong as my laziness (one enables t…

Everybody tests, sometimes on purpose.

If you think about it, everybody tests.
Infants test your ability to operate normally while sleep deprived. Toddlers and young children test their boundaries. Teenagers test the rules. There is a natural balance to our contention with and affinity for rules. Without exception, we all test the world around us. The healthy ones use this skill in their youth to build their comfort zones and navigate life with safety and confidence. For the average ones, at some point the curiosity wears off and the urge to test everything wanes so much that a child's openness is unrecognizable against the common cynical post-modern adult-onset conformity. For the truly cursed, testing everything becomes a compulsion or worse yet, a profession. I am in that third group. 
My name is Russell and this is my digital pensieve for all the things I'm curious about, all the stuff I work on professionally, and even some extra-curricular shenanigans. Don't expect too much in terms of religion or politic…