1

Recently started with Calabash on iOS. I have a simple code that does a touch("label marked:'Username'") and then uses keyboard_enter_text to enter the text, but for some reason when I run this via cucumber from command line or without setting breakpoints in Rubymine the code just runs and does not produce the desired result and the touch does not seem to do anything and the keyboard is not activated. I am doing this on a real device, (I have tried various devices).

How ever if I debug the code using ruby mine using breakpoint it produces the desired result.

I have the below setup


    $ xcode-select --print-path
    /Applications/Xcode.app/Contents/Developer

    $ xcodebuild -version
    Xcode 6.1.1
    Build version 6A2008a

    $ calabash-ios version
    0.11.4

    curl http://:37265/version
    {"app_version":"4.3",
    "outcome":"SUCCESS",
    "app_id":"****",
    "simulator_device":"",
    "version":"0.11.4",
    "app_name":"***",
    "iphone_app_emulated_on_ipad":false,
    "4inch":true,
    "git":{"remote_origin":"git@github.com:calabash\/calabash-ios-server.git",
    "branch":"master","revision":"bcc992b"},
    "screen_dimensions":{"scale":2,"width":640,"sample":1,"height":1136},
    "iOS_version":"7.1.2",
    "system":"iPhone5,2","simulator":""} 

I have checked that My App is linked with the correct calabash.framework and that it matches the gem version 0.11.4

When I debug using ruby mine then the steps run successfully (the touch works and the keyboard is activated), how ever when I run from command line or run without breakpoints in Ruby mine, the touch just seems to fail without issuing any warnings or errors. Not sure what is causing it, I have upgraded from Xcode 6.1 to Xcode 6.1.1 and that too did not help.

I have noticed similar issues reported by people in the past, but they have been around older versions of the calabash iOS gem and supposed to have been fixed in 0.11.4

When I run the app in DEBUG mode with DEBUG=1 and HTTP_DEBUG=1 I can see below

Command line run in which touch does not do anything

`

! CONNECT TO <ip>:37265
! CONNECTION ESTABLISHED
POST /map HTTP/1.1
Content-Type: application/x-www-form-urlencoded
User-Agent: HTTPClient/1.0 (2.3.4.1, ruby 2.1.5 (2014-11-13))
Accept: */*
Date: Fri, 27 Feb 2015 16:19:55 GMT
Content-Length: 97
Host: <ip>:37265

{"query":"view marked:'Problems signing in?'","operation":{"method_name":"query","arguments":[]}}

= Response

HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Content-Length: 66
Access-Control-Allow-Credentials: true
Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS
Date: Fri, 27 Feb 2015 16:19:56 GMT
Accept-Ranges: bytes
Access-Control-Max-Age: 3000

{"status_bar_orientation":"down","results":[],"outcome":"SUCCESS"}

`

Debug run from ruby mine using breakpoint

CONNECT TO <ip>:37265
! CONNECTION ESTABLISHED
POST /map HTTP/1.1
Content-Type: application/x-www-form-urlencoded
User-Agent: HTTPClient/1.0 (2.3.4.1, ruby 1.9.3 (2013-06-27))
Accept: */*
Date: Fri, 27 Feb 2015 16:18:07 GMT
Content-Length: 97
Host: <ip>:37265

{"query":"view marked:'Problems signing in?'","operation":{"method_name":"query","arguments":[]}}

= Response

HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Content-Length: 478
Access-Control-Allow-Credentials: true
Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS
Date: Fri, 27 Feb 2015 16:18:08 GMT
Accept-Ranges: bytes
Access-Control-Max-Age: 3000

{"status_bar_orientation":"down","results":[{"text":"Problems signing in?","enabled":true,"rect":{"center_x":160,"y":504,"width":200,"x":60,"center_y":526,"height":44},"id":null,"description":"<UILabel: 0x14dde8d0; frame = (60 504; 200 44); text = 'Problems signing in?'; gestureRecognizers = <NSArray: 0x14dde1f0>; layer = <CALayer: 0x14dde980>>","label":"Problems signing in?","alpha":1,"class":"UILabel","frame":{"y":504,"width":200,"x":60,"height":44}}],"outcome":"SUCCESS"}= Request

` As we can see the debug run in Rubymine seems to return information about frame ordinates that are missing in the first run

The log output at /var/folders/25/9_sb609576jcmgdbqt553ps08n5b5c/T/run_loop20150227-8208-1g7ccvv/run_loop.out for the failed run


    2015-02-27 16:19:51.871 instruments[8229:591f] WebKit Threading Violation - initial use of WebKit from a secondary thread.
    2015-02-27 16:19:56 +0000 Default: OUTPUT_JSON:
    {"status":"success","value":true,"index":0}
    END_OUTPUT

And for the successful debug run (that activated the touch and the keyboard) at /var/folders/25/9_sb609576jcmgdbqt553ps08n5b5c/T/run_loop20150227-7941-1c6mznp/run_loop.out


    2015-02-27 16:18:00.085 instruments[7962:4f17] WebKit Threading Violation - initial use of WebKit from a secondary thread.
    2015-02-27 16:18:04 +0000 Default: OUTPUT_JSON:
    {"status":"success","value":true,"index":0}
    END_OUTPUT

The run_loop.out does not seem to give any indication either.

Am I missing something ? Why does the touch not have any effect and not activate the keyboard. Any help is appreciated.

PTeng
  • 23
  • 3

1 Answers1

0

I have a couple of suggestions. These are not definitive answers, but the text is too long for a comment.

I have noticed similar issues reported by people in the past, but they have been around older versions of the calabash iOS gem and supposed to have been fixed in 0.11.4

Can you update your gem and server to the latest 0.13.0? There have been many fixes since 0.11.4.

Is it possible that you are seeing this: NSLog output can cause apps to become unresponsive during testing.?

works when debugging

I suspect this is because of timing issue, but I cannot confirm until I see some Steps or a list of commands executed in the irb.

jmoody
  • 2,480
  • 1
  • 16
  • 22
  • Thanks for your response, I will try to update the app to the latest server and also the gem and see how it goes, meanwhile I did try to run this on the simulator with same behaviour. As you have suggested it does seem to me too to. Will update after the upgrade to 0.13.0 – PTeng Mar 03 '15 at 13:57
  • Meanwhile I had a read through https://groups.google.com/forum/#!topic/calabash-ios/JWU_6VTKXMM and my problem seems to be the same. This post has been around for a while. My question is, what is the suggested approach to get around this problem (assuming that I will start using the version 0.13.0 of the gem), do we still need to inserts sleeps in the tests to get around these problems and that the lot of wait helpers that the calabash-ios gem provides still don't help get around this issue. – PTeng Mar 03 '15 at 22:19
  • That post is ancient and no longer relevant. That is the problem with doing support on Google Forums; answers cannot be curated. re: inserting sleeps - I test a bunch of app with calabash and not just toy/test apps - real apps for real high-profile clients. The wait_* methods are sufficient. The problem you are experiencing will almost certainly be fixed by updating your gem version and/or verifying that NSLog is not clobbering UIAutomation. – jmoody Mar 04 '15 at 01:41
  • thanks, I agree that its frustrating at times that google Forums can't be curated. I will try to update to the 0.13.0 gem and server and see how it goes, I am encouraged to hear that wait_* methods are sufficient. We have a lot of sleeps and Timeout::timeout(...) in the code that I have inherited and will try to change those to the calabash offered waiting methods. – PTeng Mar 04 '15 at 10:12
  • Upgraded to 0.13.0 but still no luck, could be a problem with the app itself. – PTeng Mar 09 '15 at 16:56