Introduction to Calabash

Mastering the leading techniques of mobile app testing is a part of my daily work and I got a strong desire to know everything about mobile app testing automation. So, I decided to investigate the Calabash framework.

Introduction to Calabash

What is Calabash?

By its nature, Calabash is a driver which runs the application on device. In this case, I use the bunch of Calabash and Cucumber.

At the top of the article, you can see an image which depicks the architecture of Calabash. The interaction with application occurs through performing the user actions. Taking into account the specifics of mobile applications, this can be gestures, touches, as well as checks for presence of text, buttons and many other things.

Set of tools

To use Calabash we need:

  • Android SDK,
  • Apache Ant (version 1.9),
  • Ruby version 1.9.3 (not 2.0.0 or higher),
  • Ruby DevKit,
  • Calabash from Ruby gems,
  • apk-file of the application to test.

Besides, to run the test scenarios on a certain simulator, it is necessary to pass DEVICE_TARGET attribute, and your devices must be in the same local network.

Test scenarios

Once all the required components are installed, we can write the test scenarios.

Some of the most important commands in Calabash are Query, Tap and performAction:

  • Query is used to search for objects and their properties.
  • Tap is a command to click on the object.
  • PerformAction executes such actions as: press "back" button, "menu", scroll up and down, etc.

To work with the Query request, we use Calabash console. For example, we have a step where we want to specify pressing on the "Archive" button. To do this, we find out which object has text "Archive" by writing in the command line: irb (main): 008: 0> query ("* text: 'Archive'"). As a result, we get to know that the object with the text "Settings" has id "menuSettings". Now we can press the button with corresponding ID.

Search of objects may be considered as one of the greatest disadvantages of the test automation with Calabash. When the interface changes, many locators will stop working and searching for them is quite difficult.

For writing tests, you may use predefined steps that come with Calabash (see Canned steps on GitHub) unless it is sufficient, use Ruby Api:

Example of the test scenario:

Test Scenario Example

In Calabash it will look like this:

Given /^I am on the Welcome Screen$/ do
  element_exists("view")
  sleep(STEP_PAUSE)
end
And(/^I should see "([^"]*)" on the screen$/) do |expected_mark|
  wait_for(WAIT_TIMEOUT) { view_with_mark_exists( expected_mark ) }
  sleep(STEP_PAUSE)
end
Then(/^I enter "([^"]*)" in the "([^"]*)" field$/) do |text_to_type, field_name|
  touch("UITextFieldLabel marked:'#{field_name}'")
  wait_for_keyboard()
  keyboard_enter_text text_to_type
  sleep(STEP_PAUSE)
end
Then /^I (?:touch|press) (?:done|search)$/ do
  done
  sleep(STEP_PAUSE)
end
Then(/^I logout from application$/) do
  touch("UIButton marked:'Sign out'")
  sleep(STEP_PAUSE)
end

Conclusion

All the above leads to the conclusion that the Calabash framework is very helpful for testing automation of mobile applications and can be successfully used even by the beginners.