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.go_back nor 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.