Recently, I've been focusing on learning how to write mobile automation tests which eventually are going to be run in a cloud environment. The framework that my team has decided to go with for this effort is Calabash. Some of our team members had previous experience in this framework and although we also examined Appium, because we felt more comfortable with this framework, we just went with Calabash.
One of the key components of reliable GUI automation is the ability to hook on to a property of an element on the GUI. For our desktop efforts (given WPF) we use an attached property, for our web effort we created a specific field and for mobile, we needed one as well. It is very risky to search for a myriad of properties and we avoid this approach in favor of always trying to use an "ID" field of some sort to hook on to.
What Constitutes a Good Automation Hook
1. Single Source Of Modification
Given the automation hook is an anchor for your basic GUI automation search, modifications to it should be controlled by you, the automation engineer. Although in some situations, the ID fields we hook on to serve multiple purposes (for example accessibility), we (automation engineers) should have the most control over changes. IE. We should have the ability to add and modify it, and have reasonable confidence that not many others will. Given this locus of control, we should be able to eliminate the possibility of anticipated changes.
2. Unique Naming
Given the automation hook acts as a search anchor, the more unique its name, the easier it will be to find. I've learned to always preface my hooks with some sort of search identifier, and then give it a descriptive name, relative to its appearance on the UI. It is not necessary to use existing properties to blindly name the hook. For example, if you see a button to enter an order on the UI, but its name in code is "button3", DO NOT name your automation hook "UIButton3". Instead, something like "UISubmitOrder" would suffice. The more unique the name, the less work the search algorithm will have to do.
Adding Hooks For Calabash-iOSFor default actions such as "Touch" Calabash uses accessibility labels or identifiers during the search for objects to control. For example, if you want to touch an object on a screen (via the automated script ;)) you run the command touch("view marked:'switch'"), if you were looking to touch a view with the id "switch".
So how do you get the hook in your app? You add an accessibility id. The accessibility layer in iOS is used for the iOS screen reader and other apps which deal with accessibility options. But also for Calabash-iOS during the automation flow. I am not going to expand more on the iOS accessibility framework, but if you are interested please see the list of references at the end of this post.
Calabash Hooks for Calabash-iOSIn order to add the hooks or modify your iOS project in any way, you will need to have XCode installed on your machine, and be familiar with the layout of your project. You also need to have commit permissions for your project, or at least the branch you are working out of.
Due to the fact that each project is different, I cannot predict which files specifically you will need to edit, but in my situation, I wanted to add an accessibility id to a custom viewController. A view controller is a class which controls the behavior of a screen. I wanted to add a hook to the view so I can check that it was there, as a way of ensuring the application launched the proper screen.
Please note, the code below has been modified from its' original format and does not work. It's for example purposes only!
To add the accessibility id, I simply added an accessibility identifier to the view.
I then recompiled the app and was able to see the identifier, when inspected through Calabash-iOS's IRB inspector, and the "start_test_server_in_background" method.
So there you have it. Adding accessibility IDs makes your automation effort easier...and it also makes your app more accessible :)
That's it for now!