Dependency Injection with Selenium and Spring Boot

Hello guys,

Today I am going to share something that I learned recently. I am aware that so many people probably have been using this a long time ago, but I have moved away from java and Selenium quite some time ago and I recently got back into it.

So here is a boilerplate with an automated test project using Dependency Injection of Spring Boot with Selenium, Gradle, and Cucumber.

Feel free to contribute or give any feedback !!

Github project:

How to integrate Guice + Cucumber + WebDriver

Hello guys,

Today I am going to post about something that I have been studying. So, in this project you can have an idea of how to implement Dependency Injection using Guice, a Google framework which helps you to reduce the need of new in your Java code. I found only projects that have only the Guice + Cucumber integration or only the Guice + Page Objects, so I think this one might be a good example of how to integrate everything.

Also, the project contains Page Objects and a Driver Factory, so you will be able to include other browsers and implement each one’s singularity when creating the browser, and also you still have the good practices of the POM.

I’ve added comments along the code, but feel free to ask anything or even suggest improvements.

Using Spoon with Cucumber

Hi guys,

Today I will post about Spoon which is a framework that I’ve been learning. I hope this helps someone too, because spoon is quite new and doesn’t have too much support if you want to run with Cucumber.

Spoon is a framework to run android reports and Cucumber is a BDD framework.

  • If you are using gradle, you need to open your build.gradle and add:
 classpath('com.stanfy.spoon:spoon-gradle-plugin:1.0.3') {
  exclude module: 'guava'

  • In your app-build.gradle:
plugin 'spoon'

 androidTestCompile 'com.squareup.spoon:spoon-client:1.2.0'
 androidTestCompile 'info.cukes:cucumber-android:1.2.4'
 androidTestCompile 'info.cukes:cucumber-picocontainer:1.2.4'
  • Create Spoon task in the same file:

spoon {
 debug = true
 if (project.hasProperty('spoonFailNoConnectedDevice')) {
    failIfNoDeviceConnected = true

 if (project.hasProperty('cucumberOptions')) {
    instrumentationArgs = ["cucumberOptions=" + "'${project.cucumberOptions}'"]

  • The instrumentation runner:
public class Instrumentation extends CucumberInstrumentation {
public void onStart() {
    runOnMainSync(new Runnable() {
        public void run() {
            Application app = (Application) getTargetContext().
            String simpleName = Instrumentation.class.getSimpleName();

            // Unlock the device so that the tests can input keystrokes.
            ((KeyguardManager) app.getSystemService(KEYGUARD_SERVICE)) //
                .newKeyguardLock(simpleName) //
            // Wake up the screen.
            ((PowerManager) app.getSystemService(POWER_SERVICE)) //
                .newWakeLock(FULL_WAKE_LOCK | ACQUIRE_CAUSES_WAKEUP 
| ON_AFTER_RELEASE, simpleName) //


  • Now you can use gradle command line with spoon task and pass Cucumber arguments. Like this one:
gradle spoon -PspoonFailNoConnectedDevice -PcucumberOptions='--tags @smoke'
      • Or you can use adb command line – without spoon report generation:
adb shell am instrument -w -e cucumberOptions "'--tags @smoke'" 
  • Instrument arguments
am instrument argument Description
-e count true Count the number of tests (scenarios)
-e debug true Wait for a debugger to attach before starting to execute the tests.
-e log true Enable Cucumber dry-run (same as –e dryRun true)
-e coverage true Enable EMMA code coverage
-e coverageFile “/path/ Set the file name and path of the EMMA coverage report
  • Cucumber arguments

  • Example: Use Cucumber and adb arguments
adb shell am instrument -w -e log true -e cucumberOptions "'--tags @debug'"

Thank you guys ! See you next week 🙂

Gherkin BDD comparison

Hi guys, I will post a research about the BDD engines, it is a bit old (2012), but despite this I found very interesting. I have summarised the relevant informations. The actual language to write tests with BDD is called Gherkin. And it has different implementations adopted to different programming language, the most famous:

Cucumber for Ruby

JBehave for Java

NBehave and SpecFlow for C#

Freshen for Python Behat for PHP

All of them have some common set of supported features but there’re some restrictions and abilities specific to the actual engine. So, we will collect useful features for each listed above engine and present it in some comparable form. Key features to be mentioned are:

  • Documentation availability
  • Flexibility in passing parameters
  • Auto-complete
  • Steps, scenario and feature scoping
  • Complex steps
  • Hooks and pre-conditions
  • Binding to code
  • Formatting flexibility
  • Built-in reports
  • Input data sources support
Grade Criteria
0 No support at all
1 Functionality exists but with serious restrictions
2 Major functionality exists
3 Full-featured support

Documentation Availability

  • Cucumber:
    • Cucumber group on LinkedIn – quite populated place with big number of active discussions
    • Cukes Tutorial Site
  • Freshen – honestly speaking I didn’t find any specialized resourse dedicated to freshen only. Most likely it can be discussed in the more general forums dedicated to BDD in general.
  • JBehave:
  • SpecFlow:
  • Behat:

With this sources to look the documentation of each engine, we can evaluate the criteria and the grades:

1 Documentation is available in general (it makes grade 1 at once)
2 Every feature is described and has examples (if it fits it makes grade 2)
3 There’re additional well-grown resources (forums, blogs, user groups) where we can find additional information about the engine

At the end we have:

Engine Documentation availability
Cucumber 3
Freshen 2
JBehave 3
NBehave 1
SpecFlow 3
Behat 3

Other grades:

Flexibility in passing parameters:

Engine Regular expressions support Tables support Multi-line input support Extra features
Cucumber 3 3 3 0
Freshen 3 3 3 0
JBehave 2 3 0 3
NBehave 2 3 0 2
SpecFlow 2 3 3 2
Behat 3 3 3 0


Engine Auto-complete support
Cucumber 1
Freshen 1
JBehave 1
NBehave 1
SpecFlow 3
Behat 1

Step Scenario and feature scoping:

Engine Tagging support Scoped steps support
Cucumber 3 0
Freshen 3 0
JBehave 3 1
NBehave 0 0
SpecFlow 3 3
Behat 3 0

Complex Steps:

Engine Composite steps
Cucumber 3
Freshen 3
JBehave 3
NBehave 2
SpecFlow 2
Behat 3

Hooks and pre-conditions:

Engine Backgrounds Hooks
Cucumber 3 3
Freshen 3 3
JBehave 1 1
NBehave 0 1
SpecFlow 3 3
Behat 3 3

Binding Code:

Engine Binding to code
Cucumber 2
Freshen 3
JBehave 3
NBehave 3
SpecFlow 3
Behat 2

Formatting Flexibility:

Engine Formatting
Cucumber 3
Freshen 3
JBehave 1
NBehave 3
SpecFlow 3
Behat 3


Engine Built-in reports
Cucumber 3
Freshen 2
JBehave 2
NBehave 2
SpecFlow 2
Behat 3

Input data sources support:

Engine External Data Inclusions
Cucumber 0 0
Freshen 2 3
JBehave 3 2
NBehave 0 0
SpecFlow 0 0
Behat 0 0




Sublime and BDD

A simple guide about how to write formatted BDD features in Sublime. – Download what you want in Package Control. If you don’t have the package control in your sublime, follow these steps: – Open the console:

ctrl ` shortcut

– If your sublime is 2:

import urllib2,os,hashlib; h = 'eb2297e1a458f27d836c04bb0cbaf282' + 'd0e7a3098092775ccb37ca9d6b2e4b7d'; pf = 'Package Control.sublime-package'; ipp = sublime.installed_packages_path(); os.makedirs( ipp ) if not os.path.exists(ipp) else None; urllib2.install_opener( urllib2.build_opener( urllib2.ProxyHandler()) ); by = urllib2.urlopen( '' + pf.replace(' ', '%20')).read(); dh = hashlib.sha256(by).hexdigest(); open( os.path.join( ipp, pf), 'wb' ).write(by) if dh == h else None; print('Error validating download (got %s instead of %s), please try manual install' % (dh, h) if dh != h else 'Please restart Sublime Text to finish installation')

– If your sublime is 3:

import urllib.request,os,hashlib; h = 'eb2297e1a458f27d836c04bb0cbaf282' + 'd0e7a3098092775ccb37ca9d6b2e4b7d'; pf = 'Package Control.sublime-package'; ipp = sublime.installed_packages_path(); urllib.request.install_opener( urllib.request.build_opener( urllib.request.ProxyHandler()) ); by = urllib.request.urlopen( '' + pf.replace(' ', '%20')).read(); dh = hashlib.sha256(by).hexdigest(); print('Error validating download (got %s instead of %s), please try manual install' % (dh, h)) if dh != h else open(os.path.join( ipp, pf), 'wb' ).write(by)

– Hit Enter and restart the sublime after downloaded the package.

  How to install Packages from Package Control ?

– ‘Command+Shift+P’ – Type ‘Install Package’ and enter

– Choose the package as :


Gherkin[Cucumber] Formatter


Behat Snippets

How to use ?

You can try any of these commands to generate respective file.

– ‘Command+Shift+P’ – Type: ‘Gherkin’

– ‘Command+Shift+P’ – Type: ‘Feature’

– ‘Command+Shift+P’ – Type: ‘Scenario’ or ‘Scenario Outline’

– ‘Command+Shift+P’ – Type: ‘Example’

  If you want some snippet of Given/When/Then/etc, you can use the command  ‘Command+Shift+P’ – Type: ‘Given’

Screen Shot 2015-04-01 at 21.46.24

Easy and very useful, for this reason I like Sublime ! lol Thank you guys 🙂


BDD – Summarized in 13 questions/tips and 1 example

Hi guys, today I will post a summary of a meet up that I went about BDD. It was very interesting and more clear than the others texts/posts that I found about.

1 –  Communication with all teams (business, developers, tests since beginning) is the key – Everyone should participate.

2 – What is the value of the scenario ?

3 – Could you write in another way/different steps ?

4 – Could you use the same steps ?

5 – Could you join some steps in other scenario to spend less time when you run the feature ?

6 – Your flow is decreasing the possible points of misunderstood gaps ?

7 – Are you doing the scenarios with participation of everyone in the beginning of the project ? When everyone is understanding the same thing and you starts to worry about tests in the beginning of the project, you spend less time/money than write test cases after development. Pay attention in your flow.

8 – Be curious ! Ask !

9 – Everything should be automated ? Remember that the effort spent when you automate something can be less valuable than manual testing.

10 – How many steps are you using in the scenarios, try don’t use more than 4 or 5. Make it simple.

11 – Use page object model – Better structure

12 – Be clear and objective when write the steps

13 – The feature is your documentation for end users, testers, developers. Following one of the Scrum rules, you don’t need more than this in your documentation process. Less time spent, more clear than huge documents (Because it uses examples), keeps the documentation together with the test.

14 – Use 4 layers – Example :


Thanks John F. Smart !

15 Expert Tips for Using Cucumber

Hey guys, I found these excellent tips to who are working with Cucumber and Calabash. Try follow each one to get more performance and use the best practices always 🙂

1. Feature Files Should Actually be Features, Not Entire Portions of an App

One feature per well named file, please, and keep the features focused.

2. Avoid Inconsistencies with Domain Language

You’ll get the most benefit out of using Cucumber when your customers are involved. To that end, make sure you use their domain language when you write stories. The best course of action is to have them involved in writing the stories.

3. Organize Your Features and Scenarios with the Same Thought You Give to Organizing Your Code

One useful way to organize things is by how fast they run. Use 2-3 levels of granularity for this:

  • Fast: scenarios that run very fast, e.g. under 1/10 of a second
  • Slow: scenarios that are slower but not painfully so, maybe under one second each
  • Glacial: scenarios that take a really long time to run

You can do this separation several different ways (and even some combination):

  • Put them in separate features
  • Put them in separate subdirectories
  • Tag them

4. Use Tags

Tags are a great way to organize your features and scenarios in non functional ways. You could use @small, @medium and @large, or maybe @hare, @tortoise, and @sloth. Using tags let you keep a feature’s scenarios together structurally, but run them separately. It also makes it easy to move features/scenarios between groups, and to have a given feature’s scenarios split between groups.

The advantage of separating them this way is that you can selectively run scenarios at different times and/or frequencies, i.e. run faster scenarios more often, or run really big/slow scenarios overnight on a schedule.

Tagging has uses beyond separating scenarios into groups based on how fast they are:

  • When they should be run: on @checkin, @hourly, @daily
  • What external dependencies they have: @local, @database, @network
  • Level: @functional, @system, @smoke
  • Etc.

5. Use Rake Tasks to Run Features

This provides a consistent environment for running features: this way each run uses the same set of options and parameters. This goes a long way toward maintaining deterministic results.

Another benefit is that this makes for easy integration with continuous integration tools. There is a single point of entry into the spec run, with all options/parameters encapsulated.

6. Don’t Get Carried Away with Backgrounds (Stick to Givens)

The larger the background, the greater the load of understanding for each scenario. Scenarios that contain all the details are self-contained and as such, can be more understandable at a glance.

7. Make Scenarios Independent and Deterministic

There shouldn’t be any sort of coupling between scenarios. The main source of such coupling is state that persists between scenarios. This can be accidental, or worse, by design. For example one scenario could step through adding a record to a database, and subsequent scenarios depend on the existence of that record.

This may work, but will create a problem if the order in which scenarios run changes, or they are run in parallel. Scenarios need to be completely independent.

Each time a scenario runs, it should run the same, giving identical results. The purpose of a scenario is to describe how your system works. If you don’t have confidence that this is always the case, then it isn’t doing its job. If you have non-deterministic scenarios, find out why and fix them.

8. Write Scenarios for the Non-Happy-Path Cases As Well

Happy path tests are easy; edge cases and failure scenarios take more thought and work. Here’s where having some good (and yet pathological) testers on the team can reap rewards.

Use rcov with your full Cucumber runs to find holes in coverage.

9. Be DRY: Refactor and Reuse Step Definitions

Especially look for the opportunity to make reusable step definitions that are not feature specific. As a project proceeds, you should be accumulating a library of step definitions. Ideally, you will end up with step definitions that can be used across projects.

10. Use a Library (Such as Chronic) for Parsing Time in Your Step Definitions

This allows you to use time in scenarios in a natural way. This is especially useful for relative times.

  Given a user signs up for a 30 day account

Scenario: access before expiry
  When they login in 29 days
  Then they will be let in

Scenario: access after expiry
  When they login in 31 days
  Then they will be asked to renew

11. Revisit, Refactor, and Improve Your Scenarios and Steps

Look for opportunities to generalize your steps and reuse them. You want to accumulate a reusable library of steps so that writing additional features takes less and less effort over time.

12. Refactor Language and Steps to Reflect Better Understanding of Domain

This is an extension of the previous point; as your understanding of the domain and your customer’s language/terminology improves, update the language used in your scenarios.

13. Use Compound Steps to Build Up Your Language

Compound steps (calling steps from steps) can help make your features more concise while still keeping your steps general—just don’t get too carried away. For example:

Given /^the user (.*) exists$/ do |name|
  # ...

Given /^I log in as (.*)$/ do |name|
  # ...

Given /^(.*) is logged in$/ do |name|
  Given "the user #{name} exists"
  Given "I log in as #{name}"

14. Use Parallel Step Definitions to Support Different Implementations for Features

For example, running features against Webrat and Selenium. Put these step definitions somewhere where they won’t be auto-loaded, and require them from the command line or rake task.

15. Avoid Using Conjunctive Steps

Each step should do one thing. You should not generally have step patterns containing “and.” For example:

Given A and B

should be split into two steps:

Given A
And B


Bye 🙂


Summary of Calabash iOS Ruby API – Assertions

Hi guys ! I hope you are well ! Here there are many commands of calabash-ios that are very useful 🙂



fail(msg="Error. Check log for details.")


check_element_exists("view marked:'#{expected_mark}'")




touch(uiquery, options={})


irb(main):037:0> touch("view marked:'switch'")
irb(main):038:0> tap 'switch'
irb(main):040:0> touch("view marked:'First'", :offset => {:x => 50, :y => 0})
irb(main):041:0> touch(nil, :offset => {:x => 50, :y => 0})





irb(main):043:0> keyboard_enter_char "a"
irb(main):076:0> keyboard_enter_char "More"


irb(main):044:0> keyboard_enter_text "The Quick Brown Fox"



scroll(uiquery, direction)

irb(main):082:0> scroll "scrollView", :down




scroll_to_row(uiquery, number)

irb(main):081:0> scroll_to_row "tableView", 2


{:query => "tableView",
 :row => 0,
 :section => 0,
 :scroll_position => :top,
 :animate => true}
irb(main):003:0> scroll_to_cell(:row => 13, :section => 0)
=> ["; contentOffset: {0, 0}>. Delegate: LPThirdViewController, DataSource: LPThirdViewController"]

:row the row to scroll to
:section the section to scroll to
:scroll_position the position to scroll to :top, :bottom, :middle
:animate animate the scrolling or not

each_cell(options, &block)

{:query => "tableView", #the table view to act on
 :post_scroll => 0.3,  #a pause after each action taken
 :skip_if => nil, #an optional proc to skip some cells
 :animate => true #animate the scrolling?
irb(main):008:0> each_cell(:post_scroll=>0) do |row, sec|
irb(main):009:1* puts "Row #{row} in Section #{sec}"
irb(main):010:1> end
Row 0 in Section 0
Row 1 in Section 0
Row 2 in Section 0
Row 3 in Section 0
irb(main):001:0> table_labels = []
=> []

irb(main):002:0> each_cell(:animate => false, :post_scroll => 0.1) do |row, sec|
irb(main):003:1*  txt = query("tableViewCell indexPath:#{row},#{sec} label", :text).first
irb(main):004:1>  table_labels << txt irb(main):005:1> end
=> 1

irb(main):006:0> table_labels
=> ["Cell 0", "Cell 1", "Cell 2", "Cell 3", "Cell 4", "Cell 5", "Cell 6", "Cell 7", "Cell 8", "Cell 9", "Cell 10", "Cell 11", "Cell 12", "Cell 13", "Cell 14", "Cell 15", "Cell 16", "Cell 17", "Cell 18", "Cell 19", "Cell 20", "Cell 21", "Cell 22", "Cell 23", "Cell 24", "Cell 25", "Cell 26", "Cell 27", "Cell 28", "Cell 29"]




irb(main):083:0> rotate :left


(Event) Playback

playback(recording, options={})

irb(main):103:0> playback "drag_switch_around", :query => "view marked:'switch'", :offset => {:x=>2, :y=>0}

record_begin and record_end

irb(main):104:0> record_begin
=> ""
irb(main):105:0> record_end "move_down"
=> "move_down_ios5_iphone.base64"




:place => "Tower of London"
:latitude => ..., :longitude => ...



backdoor(sel, arg)

- (NSString *) calabashBackdoor:(NSString *)aIgnorable;
irb(main):002:0> backdoor("calabashBackdoor:", "")
=> "YES"



screenshot(options={:prefix=>nil, :name=>nil})

screenshot({:prefix => "/Users/krukow/tmp", :name=>"my.png"})

screenshot_embed(options={:prefix=>nil, :name=>nil, :label => nil})

screenshot_embed({:prefix => "/Users/krukow/tmp", :name=>"my.png", :label => "Mine"})





irb(main):026:0> server_version
=> {"outcome"=>"SUCCESS", "app_name"=>"LPSimpleExample-cal", "simulator_device"=>"iPhone", "iOS_version"=>"5.1", "app_version"=>"1.0", "system"=>"x86_64", "app_id"=>"com.lesspainful.example.LPSimpleExample-cal", "version"=>"0.9.126", "simulator"=>"iPhone Simulator 358.4, iPhone OS 5.1 (iPhone/9B176)"}



irb(main):027:0> client_version
=> "0.9.127.pre1"



irb(main):028:0> calabash_exit
=> []
irb(main):029:0> server_version
Errno::ECONNREFUSED: Connection refused - connect(2) (http://localhost:37265)



irb(main):007:0> quoted = escape_quotes("Karl's child")
=> "Karl\\'s child"
irb(main):008:0> query("view marked:'#{quoted}'")



macro 'I touch "Second"'

lbl = ".......a long text......"
macro %Q[I use a step with "double" quotes and 'single' and #{lbl}]



flash("TableView index:2")



Summary of Calabash iOS Ruby API – QUERY

Just a summary of useful commands !


query(uiquery, *args)
irb(main):003:0> query("button index:0")
=> [{"class"=>"UIRoundedRectButton", "frame"=>{"y"=>287, "width"=>72, "x"=>100, "height"=>37}, "UIType"=>"UIControl", "description"=>">"}] 
irb(main):005:0> query("button index:0").first.keys
=> ["class", "frame", "UIType", "description"]

irb(main):006:0> query("button index:0").first["frame"]["width"]
=> 72

irb(main):031:0> query("tableView","numberOfSections")
=> [1]
irb(main):033:0> query("tableView","delegate","description")
=> [""]
irb(main):034:0> query("tableView",numberOfRowsInSection:0)
=> [30]
irb(main):035:0> query("tableView","numberOfRowsInSection"=>0)
=> [30]
irb(main):036:0> query("pickerView",:delegate, [{pickerView:nil},{titleForRow:1},{forComponent:0}])
=> ["1,0"]
[pickerView.delegate pickerView:nil titleForRow:1 forComponent:0]


def classes(uiquery,*args)
irb(main):001:0> classes("view")
=> ["UILayoutContainerView", "UITransitionView", "UIViewControllerWrapperView", "UIView", "UITextField", "UITextFieldRoundedRectBackgroundView", "UIImageView", "UIImageView", "UIImageView", "UITextFieldLabel", "UILabel", "UIRoundedRectButton", "UIButtonLabel", "UISwitch", "_UISwitchInternalView", "UIImageView", "UIView", "UIImageView", "UIImageView", "UIImageView", "UIRoundedRectButton", "UIButtonLabel", "UITabBar", "UITabBarButton", "UITabBarSelectionIndicatorView", "UITabBarSwappableImageView", "UITabBarButtonLabel", "UITabBarButton", "UITabBarSwappableImageView", "UITabBarButtonLabel", "UITabBarButton", "UITabBarSwappableImageView", "UITabBarButtonLabel", "UITabBarButton", "UITabBarSwappableImageView", "UITabBarButtonLabel"]


 def label(uiquery)
  query(uiquery, :accessibilityLabel)
irb(main):001:0> label("view")
[nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, "Empty list", nil, nil, nil, "Mon", "Dec 17", nil, nil, nil, "Tue", "Dec 18", nil, nil, nil, nil, "Today", nil, nil, nil, "Thu", "Dec 20", nil, nil, nil, nil, nil, "Empty list", nil, nil, "12", "12", nil, nil, "1", "1", nil, nil, "2", "2", nil, nil, "3", "3", nil, nil, nil, nil, nil, "Empty list", nil, nil, "56", "56", nil, nil, "57", "57", nil, nil, "58", "58", nil, nil, nil, nil, nil, "Empty list", nil, nil, "AM", "AM", nil, nil, "PM", "PM", nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, "Name", "First View", "First", "First", nil, "Second", "Second", nil, "other", "switch", nil, nil, nil, nil, nil, nil, "login", "Login", nil, "First", nil, nil, "First", "Second", nil, "Second", "Third", nil, "Third", "Fourth", nil, "Fourth"]




element_exists("view marked:'#{expected_mark}'")


wait_for(options, &block)
{:timeout => 10, #maximum number of seconds to wait
 :retry_frequency => 0.2, #wait this long before retrying the block
 :post_timeout => 0.1, #wait this long after the block returns true
 :timeout_message => "Timed out waiting...", #error message in case options[:timeout] is exceeded
 :screenshot_on_error => true # take a screenshot in case of error
irb(main):030:0> wait_for(:timeout => 5) { not query("label text:'Cell 11'").empty? }
irb(main):031:0> wait_for(:timeout => 5) { element_exists("label text:'Cell 20'") }
wait_for(:timeout => 30) do
    res = query("button marked:'Player play icon'", :isSelected)
    res.first == "1"        

wait_for_elements_exist(elements_arr, options={})

irb(main):008:0> wait_for_elements_exist( ["label text:'Cell 11'", "tabBarButton marked:'Third'"], :timeout => 2)
wait_for_elements_do_not_exist(elements_arr, options={})
wait_poll(opts, &block)
{:until => nil #a predicate which should return true when the condition is satisfied
 :until_exists => nil #a uiquery to function as predicate (i.e. element_exists(opts[:until_exists]))
 :timeout => 10, #maximum number of seconds to wait
 :retry_frequency => 0.2, #wait this long before retrying the block
 :post_timeout => 0.1, #wait this long after the block returns true
 :timeout_message => "Timed out waiting...", #error message in case options[:timeout] is exceeded
 :screenshot_on_error => true # take a screenshot in case of error
irb(main):023:0> wait_poll(:until_exists => "label text:'Cell 22'", :timeout => 20) do
irb(main):024:1* scroll("tableView", :down)
irb(main):025:1> end


Bye Guys 😀


Commands to use running Cucumber

Hi guys, I am writing here the commands to use when you run cucumber on Automation. It is very usefully 🙂

Launching and Customizing launch

Calabash has two ways of launching apps: SimLauncher and Apple’s instruments tool. Each has its own advantages and problems (see below).

For iOS7+ only the instruments launch method is supported. If instruments is not used to automatically launch the app touch events wont work.

Since version 0.9.154, Calabash is using instruments and UIAutomation to launch apps by default. The primary reason for this is two-fold: (a) in iOS7, Apple removed access to APIs previously used to synthesize touch events and we needed a different approach, (b) there are things possible with UIA that are not possible from “inside the app”, i.e., in the Calabash server (like accepting the Access to current location dialog or sending the app to the background).

The launch method can be controlled using environment variables. With Calabash 0.9.157+, the use of environment variables was greatly simplified. If you’re updating from a previous version, it is recommended to try removing all the environment variables, and then adding only the ones you’re sure you need.

  • DEVICE_TARGET controls which device to launch on. When set Calabash uses instruments to launch. The default is ‘simulator’ (see also Testing on Physical iDevices). You can also setDEVICE_TARGET=device or DEVICE_TARGET=UDID_OF_CONNECTED_DEVICE to pick a specific connected device, or DEVICE_TARGET=simulator to force use of instruments and simulator. (You can see the UDID of your device in the Devices tab in Xcode’s Organizer window).
  • SDK_VERSION is only used when running on the simulator. It controls which iOS version of the simulator is launched. Note, SDK_VERSION forces the launch method to be SimLauncher (not instruments). The reason for this is that the instruments tool does not support launching a simulator that is not the latest version.
  • DEVICE=ipad if you want to ensure we launch the iPad simulator. Defaults to ‘iphone’.
  • OS is deprecated and now automatically detected (it was previously used to decide which “recordings” to use for playback).
  • NO_LAUNCH is not supported when running with instruments. It tells Calabash to not automatically launch the app (it is mostly used when you want to start the app yourself – should rarely be used).
  • NO_STOP means don’t stop the app after the test completes. (It is mostly used to leave the app open in case of a test failure and should be used for debugging purposes only).
  • RESET_BETWEEN_SCENARIOS (example: RESET_BETWEEN_SCENARIOS=1) – Reset iOS Simulator between each scenario.


$ SDK_VERSION=6.1 DEVICE=ipad cucumber 

Explore interactively!

To start-up a console, you can run the command: calabash-ios console and then start a simulator withstart_test_server_in_background for iOS7 to get touch events to work.

Try starting your app using the -cal scheme from Xcode and then run calabash-ios console. This will give you a Calabash console (it is just a Ruby irb with calabash loaded).

From this console you can explore your application interactively.

You can query, touch, scroll, etc from the irb session. This information below also serves as an introduction for the APIs that are available in other place.


If your app have two buttons. Try this from the console:

irb > query("button") 

You should see something like this:

=> [{"class"=>"UIRoundedRectButton", frame"=>
{"y"=>287, "width"=>72, "x"=>100, 
"height"=>37}, "UIType"=>"UIControl", 
"description"=>"<UIRoundedRectButton: 0x7d463d0; 
frame = (100 287; 72 37); opaque = NO; autoresize = RM+BM;
 layer = <CALayer: 0x7d46ae0>>"}, 
{"class"=>"UIRoundedRectButton", "frame"=>
{"y"=>215, "width"=>73, "x"=>109, 
"height"=>37}, "UIType"=>"UIControl", 
"description"=>"<UIRoundedRectButton: 0x7d3a760; 
frame = (109 215; 73 37); opaque = NO; autoresize = RM+BM;
 layer = <CALayer: 0x7d3a8a0>>"}] 

This is actually an array with two objects that are descriptions of the two buttons. For example, the class of the first button is “UIRoundedRectButton”. We can dive into this information using Ruby programming:

irb > result = query("button") ... irb > btn1 = 
result[0] ... irb > class1 = btn1["class"] => 

The query function takes a string query as an argument. The query argument is similar to a css selector, for example we can do:

irb > query("button index:0 label") => 
[{"class"=>"UIButtonLabel", "frame"=>{"y"=>9, 
"width"=>38, "x"=>17, "height"=>19}, "UIType"=>"UIView", 
"description"=>"<UIButtonLabel: 0x7d41120; frame = 
(17 9; 38 19); text = 'other'; clipsToBounds = YES; opaque 
= NO; userInteractionEnabled = NO; layer = <CALayer: 

This means “find the first button, and then inside of that find all labels”.

Query may also take parameters that are mapped to Objective-C selectors on the found object.

irb > query("button index:0 label", :text) => 

Query is very powerful, but the full syntax and power of query is beyond the scope of the Getting started guide on GitHub.


Anything that can be found using query can also be touched. Try this while you watch the iOS Simulator:

irb > touch("button index:0") 

Notice that the button is touched (turns blue), although this button doesn’t do anything.

You can also touch the tab bars:

irb > touch("tabBarButton index:1") 

The filter: index:1 means that it is the second tab-bar button that should be touched.

Setting accessibility

Identifiers and accessibility


In general UI views are found using accessibility ids or labels. Go to the “First” tab in simulator, and then in your console session try this:

# query for the switch on the "First" tab irb > 
query("view marked:'switch'") [ [0] { "class" => 
"UISwitch", "frame" => { "y" => 148, "width" => 
79, "x" => 106, "height" => 27 }, "UIType" => 
"UIControl", "description" => "<UISwitch: 0x7d3ffb0; 
frame = (106 148; 79 27); <snip> >>" } ] 

You can set the accessibility attributes of UIView from the Interface Builder or programmatically.

In some cases the UIKit framework will set the accessibilityLabel for you if you don’t explicitly set the value.

For example, UITabBarButton will have an accessibility label that is the same as title of the tab bar button.

irb > query("tabBarButton marked:'Second'") [ [0] {
 "class" => "UITabBarButton", "id" => nil, "rect" 
=> { "center_x" => 120, "y" => 520, "width" =>
 76, "x" => 82, "center_y" => 544, "height" => 48 
}, "frame" => { "y" => 1, "width" => 76, "x" =>
 82, "height" => 48 }, "label" => "Second", 
"description" => "<UITabBarButton: 0x857e010; frame = 
(82 1; 76 48); <snip> >" } ] 

Whenever possible, you should use the accessibilityIdentifier of UIView and reserve the accessibilityLabel for providing localized Accessibility traits.

- (void) viewDidLoad { [super viewDidLoad]; UISwitch 
*switch = self.wantsCoffeeSwitch; # ex. queries # query 
"view marked:'wants coffee'" # query "switch 
{accessibilityIdentifier LIKE 'wants coffee'}" # query 
"switch marked:'wants coffee'" 
switch.accessibilityIdentifier = @"wants coffee"; # 
accessibilityLabels should be localized and follow the 
conventions # described by Apple's Accessibility 
documentation if (switch.isOn == YES) { 
switch.accessibilityLabel = NSLocalizedString(@"Wants 
coffee"); } else { switch.accessibilityLabel = 
NSLocalizedString(@"Does not want coffee"); } } 


Thank you guys ! If you have any question, just write below. Bye !!