Home > Programming, QA, Test and Automation Stuffs, QA, Test and Automation Stuffs > Identify properties and filter in the query – Calabash

Identify properties and filter in the query – Calabash

Hello guys ! I hope you are well :)}

I will show how you can search for other property of an element beyond that appears when you query an element with calabash.

A simple query wich returns a property is:

query("UIView", :textContent)

But if you want returns color, or other property beyond the simple one (textContent, y, x, rect, class, id, label, etc…). You can see what types of properties/attributes this element/class can returns and use. You can see the list of properties/attributes that each element/class returns here. All that you need to know is the class of the element. First, you do the simple query and discover the class of this element and after search this class in the UIKit of iOS. There is a short-hand form of specifying UIKit class-names. For example, if you just write label this is automatically translated to UILabel (which is a common UIKit class). In general, ClassName expressions that don’t start with view: get re-written. For example:xyzAbc will get re-written to view:'UIXyzAbc'

So if you discover that an element uses the class UIView, you can click in correspondent class and discover the list of attributes/properties that you can search for. Example:

- :backgroundColor
- :hidden
- :alpha
- :opaque
- :maskView
- :layer
- :accessibilityLabel

In Android the Views (also the TextView) can have almost anything as a background not just a color (a bitmap, a shape, a gradient color, etc). Because of this there is no way to get the background color of a view (it is not stored).

There is a simple form of specifying classes. For example, if you just write button this matches all views which have a class with simple name “button” (or “Button” as this is case in-sensitive). Remember that the simple name of a class is the last segment of the fully qualified class name, e.g., for android.widget.Button it is Button

This is not a limitation of Calabash but the Android system. You can get any property of an Android view if it is accessible.

The property names map to “getter”-methods of the view objects. In general prop:valwill try to call:

  • prop()
  • getProp()
  • isProp()

You can query the following colors on the TextView (nothing is background):

- text color :currentTextColor
- hintTextColor :hintTextColor
- highlight color :highlightColor
- shadow color :shadowColor

You can identifying the properties of the class if you open the project and open the class file that you want to know the attributes. There you can find the properties that you can filter with calabash too.

– Examples:


query("RadioButton id:'radio_male'",:setChecked=>true)
query("RadioButton id:'radio_male'",:setChecked=>0)



query("CheckBox id:'check_update'",:isChecked)
query("CheckBox id:'check_update'",:isChecked=>1)
query("CheckBox id:'check_update'",:checked)
query("CheckBox id:'check_update'",:setChecked=>true)

 Progress Bar:

query("RatingBar",:method_name=>'getProgress', :arguments=>[])
query("RatingBar",:method_name=>'setProgress', :arguments=>[5])



query("datePicker",:method_name =>'updateDate',:arguments =>[1990,11,30])



query("EditText id:'email_input'",:getText)
query("EditText id:'email_input'",:text)
query("EditTextid:'email_input'", :method_name=>'setText',:arguments=>['test@test.com'])
query("EditTextid:'email_input'", :method_name=>'getText',:arguments=>[])

indexPath: A special construct that supports selecting cells in UITableViews by index path. The general form is:

"tableViewCell indexPath:row,sec"

where row is an number describing the row of the cell, and sec is a number describing its section.

In general, you can filter on any selector which returns a simple result like a number, string or BOOL.

"button isEnabled:1"


iOS Directions:

There are four directions descendantchildparent and sibling. These determines the direction in which search proceeds.

Both descendant and child looks for subviews inside a view. The difference is that descendant keep searching down in the sub-view’s subviews, whereas child only looks down one level. The direction sibling searches for views that are “at the same level” as the present view (this is the same as: first find the immediate parent, then find all subviews except for the view itself).By default the direction is descendant, which intuitively means “search amongst all subviews (or sub-views of sub-views, etc).” But you can change the traversal direction. Here is an advanced example:

query("label marked:'Tears in Heaven' parent tableViewCell descendant tableViewCellReorderControl")


Android Directions:

There are three directions descendantchild, and parent. These determines the direction in which search proceeds.

Often, query expressions are a sequence of ClassName expressions. For example:

 "linearLayout editText"

this means “first find all linearLayouts, then inside of those, find all the editText views”. The key here is the word inside. This is determined by the query direction.

By default the direction is descendant, which intuitively means “search amongst all subviews (or sub-views of sub-views, etc).”


  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: