Tuesday, August 12, 2014

frank-cucumber - Accessibility Labels and Timing

Our Current Project and frank-cucumber

compiler_complaint.png

A few items caused me much headaches and had me refactor my code on the current project I am working on: Accessibility Labels, timing (aka, “race”) issues, UIAlertViews, system call-backs and user’s location -- all of these require further details.

“accessibilityLabel”
Accessibility labels are items found in XCode’s Interface Builder under the “Identity Inspector”

Screen Shot 2014-08-07 at 3.11.49 PM.png
These can be assigned through this window or programatically. “.accessibilityLabel” is a property of any view. In the above case, I added the accessibility label to the UIButton.

Frank will also extrapolate an “accessibility label” from other Interface Builder properties. Such as a UIButton’s title. In frank inspect Safari’s view, the “Submit” button under the “New User” has an “accessibilityLabel”: ‘Submit’. However, it has an empty “Accessibility Label” field.

Frank is smart enough to create the accessibilityLabel from here:

Screen Shot 2014-08-07 at 3.18.30 PM.png

If there is no “Title”, Frank will create the “accessibilityLabel” from the image associated with it. Such as: “submit.png”

Add/Change Accessibility Label
Let’s say there is a “view” that you want Frank (and your user) to access, but it hasn’t created an “accessibility label” for it. You can add one that Frank can recognize. You must:
  • Find the “view” in XCode that you want to recognize
  • Type in the accessibility label - in IB or programmatically using .accessibilityLabel property and SAVE.
  • In bash - return to your app’s folder and run frank build , frank launch, frank inspect.
  • frank build_and_launch is also an option.

You will see that the accessibility has been added/changed accordingly in the Symbiote that frank inspect launches. Happy cucumber!

Timing (aka “race”) issues

There were quite a few cases when I swore my code was correct, but the tests would still fail. These turned out to be race issues, i.e. timing. The code moved faster than the view.

To find out if your code is failing due to timing, add a pause in your code using sleep.

Let’s say that in our “newtest” feature, it always fails when at the last step.

Given I launch the app                                                  # Frank/features/step_definitions/launch_steps.rb:5
Then I should be on the Home screen                                     # Frank/features/step_definitions/newtest_steps.rb:5
When I navigate to “Events”                                 # Frank/features/step_definitions/newtest_steps.rb:9
Then I should be on the Events screen                                    # Frank/features/step_definitions/newtest_steps.rb:13

Failing Scenarios:
cucumber Frank/features/inputlogin.feature:3 # Scenario: Then I should be on the Events screen

1 scenario (1 failed)
4 steps (1 failed)

But your code looks like this:

Then /^I should be on the Events screen$/ do
  check_element_exist “view:’UIButton’ marked:’Events’”
end

You have checked accessibility labels, spacing, punctuation. It’s all good! Now, add a sleep method with any number of seconds.

Then /^I should be on the Events screen$/ do
  sleep 2
  check_element_exist “view:’UIButton’ marked:’Events’”
end

If everything passes, then you can refactor to use more idiomatic code using the following:

Then /^I should be on the Events screen$/ do
       selector = “view:’UIButton’ marked:’Events’”
       wait_for_element_to_exist( selector )
       check_element_exists( selector )
end



p.s. I love xkcd comic strip at http://xkcd.com. These comics are from there. If you love them too, do go buy his book and/or see him on his"What If" book tour!

No comments:

Post a Comment