Like most programming tasks once you setup the basic framework most things will be smooth sailing from there on out. I feel like this automation library will be no different. We encountered a few bugs recently which indicated I should really begin working on this. Both were discovered in pre-deploy quality control but I would rather avoid this occuring again. The first was logging out was broken leaving causing a transition to an invalid view controlller. The second was a value was no longer properly passed down through various screens for editing, causing the forced assumption an optional wasn’t nil.

Unlike most web applications I’ve automated in the past, this particular automation suite must deal with dialogs on login and not just to the typical single onboarding but several in different states of the application. I’m totally a fan because it makes the application easier to use. However I’m debating on needing a unit to inferer state on log in to ‘stablize’ the state.

UITableViews and Appium don’t play well together. Might be the XCUITest suite behind Appium that doesn’t play well, but wow. Can’t find elements or IDs or anything. Sad. The accessibility identifiers I placed on the cell’s prototype in the Storyboard weren’t there at runtime. To remedy this I attached it in tableView(tableView: UITableView, cellForRowAtIndexPath indexPath: NSIndexPath) -> UITableViewCell. Probably not the best approach, but I’m worried about this working now. Tried that on the next table…and nope. The cell itself receives the accessabilityIdentifier, maybe the table requires one also? There was an additional component with the same accesibility identifier, perhaps that was cuasing problems? Also, I was scoping to a specific element because of a bad architecture. Originally I went with a Screen -> Component structure where Component would only recieve it’s root. Would be fine but the output looks scoped. The VC doesn’t have accessibility enabled, however a cell within the table does. Will that be my missing peice? Bingo! At least one cell in the table must be accessible for the table to report accessibility. That was really annoying!

Round three with the tables! Failed with the cell isn’t marked as accessible. Now the VC’s root view isn’t accessible, the table isn’t modified, however the cell is marked as accessible with an identifier. Worked! woot! Learning.

Next up to bat is a customized UI component composed of a number of other components. Let’s see how this fairs. This particular component opens a UIPickerView and has two components which need to be manipulated. The component also displays a UIToolbar which may be the prefered way to interact with the element. XCTest appends the suffix of ‘, X of Y’ for the number of elements within the set. Peachy. There was a suggestion on the Appium Github issues of using the UIPickerView’s string result method, but in this case I can’t do that. set_value and setValue didn’t work. I really wish there was a simple work around. Perhaps sending key events? I gave up and reacted to the ending of an event to push the value through a text field.