So basically UI Automation is really hot right now. You see a lot of test conferences where big companies are talking about their solution to automate your repetitive integration tests for mobile platforms. We know that for websites, the automation is already mature enough. But since the introduction of the smartphone and apps, companies are again on the hunt for the holy grail for uiautomation for mobile platforms.
If I’m speaking of uiautomation for mobile platforms, I mean the two biggest operating systems Android and iOS. A lot of companies doing investigations on what the best way is to work for automation. Some managers thinks it will reduce costs because you can fire your big group of testers, because the machines will do their jobs now, right? Well mister manager, you are wrong about that. UIAutomation is helping your tester to create more time to spend on finding new bugs, uiautomation is only there to verify the existing functionality is not broken.
So cool we have our target, we want to have our automation in place so we can reduce our time in regression and can deliver new functionality to the customer in a shorter time than we currently have. So there are a lot of “tools” which can do the job for you. So we have HP Test suite, Appium and other solutions which all have the same problem:
They are not NATIVE supported.
So for Android there are three native frameworks:
Espresso is the latest framework from Google for UI Automation for Android. This framework is used in a white box testing environment. This means that it knows all the inside info of the app, like the resource ids from views like buttons and edittexts. I already hear your question: “So what’s the deal with this? Appium can also act on these resource ids.”
Well you know that moment where you have a nice test case where you tap some buttons insert some cool text in your edittexts and than you come to that screen with… that list. That’s right, that list with 400 items in it. And to make things worse, you have to look for a certain item in that list. So with Appium you have something where you scroll, look if you see the text you are looking form if not continue with one scroll and repeat the whole action again until you find it. This takes a lot of time I can tell you.
With Espresso it makes these kind of steps easier, because your automation code lives inside the app, you have basically access to everything, even the content of your 400 item list! So with Espresso you won’t have to worry about scroll and search, you can already search for that item in the list and navigate straight to it. Another benefit of using Espresso is that it can keep track of all your backend calls, so it knows when a call to the backend is finished and can continue with the test. So no use of hardcoded wait for elements and the horrible Thread.sleep(3000) stuff.
The Robotium framework was developed in 2010 by the company Robotium. This framework is used for black box testing, like Appium and others. But the benefit of this framework is that it also supports hybrids app.
So how does Robotium works? It basically have some standardised steps for you which you can call from the Solo class. So for example you can click on an element with text and enter text in an edittext. Robotium has also a screenshot functionality so you can validate if your view is correctly shown on the screen. One of the big benefits of this framework is that you can use it across different activities. One of the down sides it doesn’t keep track of different threads like Espresso does. This means that if you have a call to the backend running, Robotium doesn’t wait for it unless you set a specific wait statement.
In the near future I will write my findings on using Robotium in combination with Cucumber to run a full testsuite on the DemoBankApp project.
UIAutomator framework is Google’s answer to Robotium. This framework is mainly focussing on the cross-app UI testing part. With UIAutomator you have the ability to turn off the wifi for example or navigate through the Android OS as where Espresso is limited to only the app itself. This framework has also a good tool called UIAutomatorviewer where you can make a screenshot from the active screen and inspect all the elements like button id’s. sizes and text values.
UIAutomator is basically the same as Robotium, it has a nice screenshot function, can open the notifcation shade, can access the hardware buttons like back, home, menu, d-pad and can rotate the device orientation.
The API contains the following methods where you can write your test cases with:
- UiCollection: Enumerates a container’s UI elements for the purpose of counting, or targeting sub-elements by their visible text or content-description property.
- UiObject: Represents a UI element that is visible on the device.
- UiScrollable: Provides support for searching for items in a scrollable UI container.
- UiSelector: Represents a query for one or more target UI elements on a device.
- Configurator: Allows you to set key parameters for running UI Automator tests
Because I have a little experience with UIAutomator I would definitely do a proof of concept in the near future with UIAutomator and Cucumber in the DemoBankApp project
So here you have it, three nice frameworks which are supported by Google. I really am triggered to dive deep into Robotium and UIAutomator. So expect in the near future more blog posts about these topics. If you have any questions or request about these frameworks for the upcoming blog posts, please contact me.