Mobile Automation Flashcards
What were you the main components of your mobile automation framework at Comcast?
We used Cucumber, Ruby, and Calabash to automate both the iOS application and Android application.
We ran our tests using a local machine on real devices.
How did you use Cucumber?
We used Cucumber as the test driver for our automation. Regression tests were written as feature files – including lots of scenario outlines – and step definitions. The Gherkin was straight-forward and closely matched the English of our Regression test cases, and the Step Definitions translated the cukes into actionable code.
A lot of the work I did was refactoring the step definition code. I used an almost psuedo-DSL and encapsulated most of the actual driver logic within the PageObject and utility classes.
How were your files organized in your framework?
Feature folder containing the feature files and folders: step_definitions, support, and ios_pages.
In the Pages folder, we defined our _base class and PageObjects.
In the Support folder, we kept our launch logic, pre-stop-hooks, env file, credentials.
In our launch class, we defined the Before block to start the Calabash driver, and the After block to quit the driver. In the env file we instantiated all the Page Objects, and had some helper methods and configurations. I think I overwrote the naming logic of the screenshot method. You could also put stats gathering logic here.
How would you run your mobile automation tests?
Download the repo and run bundle install, all the dependencies (besides Ruby and Bundler) were in the gem file.
You’d just export the environment variables to your .bashrc or .bash_profile (device_target, app_bundle_path, bundle_id).
then run the cucumber command
For iOS you had to have a special compiled build which we put on a private server.
For Android we just had to have the APK locally.
How did you write your tests? What did you decide to test?
Our tests were pulled straight from our regression suite. One of my accomplishments was after resolving a lot of ambiguities in the regression suite, I made the Gherkin match the language. I also added test case IDs to the comments just before the features.
Essentially, we used a modules pattern, where we divided up the application into large modules of functionality, typically around specific pages and workflows, and defined scenarios.
I like to have small, discrete tests, that test one thing and are isolated – don’t rely on the other tests to pass. Each test case will have a setup/teardown.
Why did you use Calabash and not Appium?
There were already some tests written in Calabash. It wouldn’t have been my first choice – coming from a Selenium background, and I had a little experience with Appium at Neat, but I actually liked some aspects of Calabash a lot.
I liked the console mode, which was like an interactive Calabash shell to dynamically interact with my app, similar to what I was used to with IRB and Selenium.
calabash-ios console
start_test_server_in_background
What did you use for reporting?
We just used the Cucumber generated HTML reports. We never got to the level of integrating the tests into CI so there wasn’t really many people looking at the reports, though we did integrate them into our Final Testing Reports.
I would have liked to use a test framework for reporting I heard of called Allure, which has RSpec support.
