KIF and accessibility identifier

[olar...@gmail.com]

Hi all,

I'm new to this mailing list, sorry if I bring up again a widely discussed topic - I did a quick search and couldn't find much info, so I thought I'd bring it up directly.

I'm currently evaluating KIF for automating my iOS apps, and really like what I'm seeing so far. The xcode and bots integration looks really great, coming from the calabash/frank world it's a big step forward.

Biggest problem I ran into is the use of accessibility labels by KIF, rather than accessibility identifiers. I don't want to start a holy war on labels vs identifiers but the bottom line in my case is that I simply can't use accessibility labels.

Long story short, I have multiple translations and of course the app can behave slightly differently based on the language (Japanese usage of sortable first/last name comes to mind, but there's also other very subtle differences). So I can't get away with accessibility labels in our case.

Fine, it's a free country, code is on github, I can try and patch KIF to support labels and identifiers, but before I head down this path, I'm wondering if a pull request to add identifier support would be accepted, or if for whatever reason, this is completely off the table?

I've noticed pull request https://github.com/kif-framework/KIF/pull/215 has been closed without being merged, but with no extra details. Any reason for that?

/kra

[Brian Nickel]

As I usually do, I am going to strongly recommend against using accessibilityIdentifier for accessibility testing, except in cases where you need to grab something by an identifier because a label is inappropriate.

Looking at your problem, your app behaves one way in one language and a different way in another.  This means A) you will want to control your test environment to ensure the language matches what you are testing and B) more importantly, you may have interesting behavior to test for each language.  You may *want* to validate that your results are sorted in a given order in Japanese.

You can address A by adding the -AppleLanguages command line argument to your test phase.  You can open your scheme, select the test phase, and under "Arguments Passed On Launch" add -AppleLanguages (en).  When you run your tests, they will always run in English regardless of what the simulator is set to. Learned this trick at http://nshipster.com/launch-arguments-and-environment-variables/

You can address B in a similar fashion but with more overhead.  You need to create a second target, say "Acceptance Tests (JP)" for running your Japanese-specific tests.  You then need to create a second scheme that has these tests.  Unfortunately, you only get one simulator launch per scheme.  I personally would put all my core logic stuff into the language I'm most comfortable with, and limit my language-specific tests those unique behaviors.

But now that I've told you what I'd do, KIFUITestActor internally has a method:

- (void)waitForAccessibilityElement:(UIAccessibilityElement **)element view:(out UIView **)view withIdentifier:(NSString *)identifier tappable:(BOOL)mustBeTappable

which is analogous to the main building block method of the framework based on label, value, traits.  I plan to expose this publicly and then it should be trivial for you to implement whatever behavior you want by copying and tweaking existing methods.  I'll probably do it later this week.

Brian