Mobile Automation Project Example

Mobile Automation Project Example

In my previous article I explained why it is not a bad idea to use Cucumber as an automation tool. In this one I’ll show using the real example how it works. Also we will get closer to mobile automation, as for the sample project I will use Calabash iOS and Android. You’ll ask why Calabash and not Appium? The answer is simple – I just like this tool. Later I’ll publish article series about iOS mobile automation tools evaluation, where I’ll compare KIF, Appium, XCUITest, EarlGrey and Calabash.

The fact, that this example is based on Calabash, doesn’t mean that you will be unable to apply the same approach to another tool. This approach is not locked by one particular technology.

So, less words more actions. Let’s start with the sample project. You can find the project here:

Sample project

The project contains Calabash project itself and two applications to test, one for Android and another for iOS. Calabash project is structured in such a way that one test will work for both iOS and Android. In tests I’ll use page objects and reusable step definitions.


If you have your mobile infrastructure in place, the project should work out of the box. The only thing you’ll need is to run `bundle install`. If you haven’t worked with mobile projects before, you’ll have to install:

  • Xcode for iOS
  • Android instruments for Android
  • Ruby > = 2.2.0 (2.3.1 is recommended)

More information about setting up your environment you can find here:

Test running

Test are running from the console.

To run all the iOS tests :

bundle exec cucumber –p ios

To run one particular iOS test :

bundle exec cucumber –p ios ––t @sample_1

To run all the Android tests:

bundle exec cucumber –p android

To run one particular Android test:

bundle exec cucumber –p android ––t @sample_1


RubyMine is a really good IDE for writing Cucumber tests. The main advantages in comparison to another tools are the following:

#1 It has auto completion for Cucumber. That is really helpful when you have a lot of step definitions.

#2 You can jump through the methods that makes debugging easier.

Classes and methods accessibility

In order to see all the classes, methods and page objects from the tests I use cucumber.yml. It requires all the files from directories that you specify in the yml file. Also, yml configuration file allow you to require different files for iOS and Android tests.

Page objects

Page objects are very useful. Using them, you can reuse one object in different tests without duplicating the code.

iOS page objects for this sample project are here.

Android page objects you can find here.

As you can see page objects represent addresses of the element using classes, text, ids or their combinations as well as hierarchy dependencies.

There is an example of checkButton address using class UIButton and text “Check the number”:
class WelcomeScreen < BasePage
  def checkButton
    "UIButton marked:'Check the number'"
You can access this object from every place of your test simply calling: WelcomeScreen.checkButton

Step definitions

Step definitions are the translations of your Gherkin steps to a programming language. So, when you are calling a step like:

And I tap on WelcomeScreen.checkButton

It will be translated into:
Then(/^I tap on ([^\"]*)$/) do |element|
path = get_path element
touch path


Tags can be added to each test. You can give a unique tag to a test and then run the test using this tag. (e.g. bundle exec cucumber –p ios ––t @sample_1). Also you can add behavior to a specific tag, for example add a tag @reset_simulator and then implement the simulator reset function in your “before” method.

Test applications

There are two similar one-view applications for Android and iOS. In this application you can enter data and check if this data is an Integer. If data is integer you’ll see the green label with confirmation; if data is something else you’ll get the red label with an error massage; if data is empty you’ll get the yellow label with the call to provide the value.

Using Cucumber in your tests

Tests live in .feature file. When opening the feature file, you can see how I reuse steps to create 3 different tests without making them look like documentation. So, instead of using one complex step for each test, I use several reusable steps that you can apply to any other test you’ll write afterwards. That is true, that readability is going down, but that allows me to write other tests reusing same page objects and steps without duplicating the code. For example, you can try different inputs; clicking on other elements; double clicking and etc. without writing anything but changing page objects, input and colors in step definitions.

Now when you have general knowledge about the project, try to launch it and write your own scenario! Believe me, it is easy.

As you may have noticed, this article was aimed to introduce you in the sample repository. In my next articles I will explain this more detailed, based on this sample project that I’ll constantly enlarge.

4 thoughts on “Mobile Automation Project Example

  1. Great article! very simple and very beneficial.
    I have a suggestion, what about using the “Background” keyword instead of duplicating the “Given” in each scenario. Am I correct?

    1. Hey! Sure, it can be simplified even better using the Scenario Outline:

      @ios @android @sample_1
      Scenario Outline: Choose a number
      Given I am on WelcomeScreen
      And I type “<text>” in WelcomeScreen.inputField
      And I tap on WelcomeScreen.checkButton
      Then I see “<result>” text
      And the color in WelcomeScreen.resultLabel is <color>
      | text                 | result                                        | color  |
      | 1234               | Your value is an integer:1234      | green |
      | This is a string | This is a string – is not an integer | red     |
      |                       | Entry field is empty                     | yellow |

      Idea was to show how you can create multiple tests using page objects and reusable steps, I didn’t want to make it look complicated for users who is not familiar with Cucumber 🙂
      I’ll definitely create some more tests and show how you can reduce amount of lines in your feature files in the separate article. Thanks for the idea 😉

  2. Thank you, Joe, for helping me out from Calabash Android set-up and configuration. And also this article helped me a lot to configure calabash on windows 8.1.

    Thanks again 🙂

Comments are closed.

Comments are closed.
Skip to toolbar