Continuing iOS automation
• Mark Eschbach
Continuing my approach to automation becuase I introduce another bug. It would be really helpful if we could run the entire automation process for each build, or at least the most recently successful build. So I’m still working on the critical path still, and I’ve hit a roadblock on the dealing with a UIPickView. As an aside, I’ve realized it probably would have been better to have an object which captures the return value of each invocation via
method_missing so I don’t have to deal with the lvalue for everything; improvement for later anyway. Lots of improvements for later. I’m just trying to get this delivering value at this point.
So I’m a little bit bewildered on how to deal with the
UIPickerView at this point. Most Appium responses and articles mention
setValue(some_value), so I’m hoping that works. So I gave the
UIPickerView an accessibility identifier, but my next wonder is how to get each component. Given I’m not in a rapid edit-test cycle, I’m going to guess here the children off the
UIPickerView are the components in order. To confirm I’ll be dumping the values of each element using the XPath selector
Alrighty, so moving on; I’ve got to simulate a user signing. This one is going to be interesting: I’m not actually using the Appium libraries, just straight webdriver via the Ruby libraries. Well, no luck there. Looks like I’m stuck using Appium’s library because I dont’ want to reverse engineer the wire protocol integration which isn’t obvious from from device/touch_actions.rb. Right, that is why I didn’t do that. Appium is stuck at
~> 2.50 while I’m using
selenium-webdriver (= 3.0.3). And I remembered that Bundler has issues around resolving dependnecies with the opinion you should just fork. Hmm…not sure how to handle this one. I don’t like forking gems which drive complicated integrations, perhaps it would be easier to pull the specific touch wire out after all.
When attempting to locate how the message is sent to the remote driver I discovered in the base appium/driver.rb @ line 501 they are using the
@driver.extend Selenium::WebDriver::DriverExtensions::HasTouchScreen which looks promising. Time to try it out. Also found
require_relative which looks cool; I’ll have to use that in the future. On to testing the registration. While trying to decipher the Selenium documentation I found the library Ricardonacif/touch_action. I think I’ll give it a try so I don’t have to worry about the details of touch. Well…nevermind, that uses YUI under the hood, so I can’t use that. Back to the drawing the driver directly.
Alright, I coded a lot before I started testing. Apparently
driver.navigation does not exist, sad times.
driver.goBack works. There is a
Selenium::WebDriver::Navigation, but the
back method calls
driver.go_back. So after much frustration I’ve come across a (StackOverflow article about the navigation controller)[http://stackoverflow.com/questions/24318660/ios-get-uinavigationbars-back-button-in-order-to-set-accessibility-properties]. In thoery it should simply have the accessibility identifier
Done. And boy do I feel like I made a mountain out of a mole hill. Totally shot that one. A lot easier than I thought. Alrighty, still got some problems but I’ll have to leave them until tomorrow.