dyld: lazy symbol binding failed: can't resolve symbol _XCStringFromRect in /Applications/Xcode-beta.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/usr/lib/../../Library/Frameworks/XCTest.framework/XCTest because dependent dylib #12 could not be loaded
We've seen failures where there are different settings locally and in CI regarding having the simulator's keyboard enabled. This leads to a rabbit hole of investigating why tests that seem to work fine fail on CI.
It would be interesting to have a setting/configuration option that would hard fail tests when the software keyboard wasn't enabled in the simulator. It would be even better if there were a way from the test to enable the setting, but I think that would require doing some horrible things on the machine that is hosting the simulator.
Improvements around this should make this failure mode obvious. Ideally, it would be enabled by default, but opt-out for folks that want the simulator keyboard to be disabled.
This bug has existed for a while, but I hadn't gotten around to fixing it until verifying the fix in #1020, which started hitting this in our app.
The issue is that if a table view cell contains a matching element, and that element is fully offscreen but the tableViewCell is partially onscreen, we won't scroll it into view during the matching operation (in `-[UIView(KIFAdditions) accessibilityElementMatchingBlock:notHidden:]`) and tapping the element will fail.
The fix here is that right before attempting to tap an element, if it isn't currently tappable on the screen and is contained within one or more UIScrollView's, attempt to reposition the scroll views such that the element to tap is visible on the screen.
Allows the consumers to specify custom `UICollectionViewScrollPosition` of the cell they want to scroll to. `UICollectionViewScrollPositionCenteredHorizontally | UICollectionViewScrollPositionCenteredVertically` remains to the default value.
The original KIF authors (@efirestone, @bnickel to name a few) allowed an addition of finding/tapping elements by accessibilityIdentifier as an addition (think plugin) to KIF. I vaguely recall reading a discussion regarding accessibility identifiers, stating that we should focus on the use accessibilityLabels, as that was Apple's recommendation. People contributing to KIF added identifier tests as per their own need, but parity between accessibility label methods and identifier methods was never maintained.
Now that Apple has shifted gears in that they suggest using accessibility identifiers, we need to revisit two things:
1. How KIF integrates the accessibility identifier methods. Currently, it's like a plugin. You don't get them for free by merely installing KIF. You have to explicitly include them.
2. Parity between label and identifier methods.
An example of the lack of parity is the fact that you can call tryFindingTappableViewWithAccessibilityLabel: with traits, but you cannot call tryFindingTappableViewWithAccessibilityIdentifier: with traits (in retrospect, that method does not exist at all for you readers, except for me as I've added it to my own KIF implementation but have not pushed it up in a PR.) which further proves my point.
@justinseanmartin @RoyalPineapple I invite your input to this discussion.
Currently, we run our tests with timings of:
UIApplication.sharedApplication.animationSpeed = 4.0;
KIFTypist.keystrokeDelay = 0.0025f;
KIFTestActor.defaultAnimationStabilizationTimeout = 0.1;
KIFTestActor.defaultAnimationWaitingTimeout = 2.0;
Sometimes, when typing in 15+ character strings and then immediately transition views, the full text doesn't get picked up. I think there is probably some tweaking that needs to happen in `-[KIFUITestActor enterTextIntoCurrentFirstResponder:fallbackView:]`. Instead of:
NSTimeInterval remainingWaitTime = 0.01 - [KIFTypist keystrokeDelay];
Maybe the maximum wait time needs to be scaled based off how long the string being typed is?
I suppose this is the downside of not using `enterText:expectedResult:`, but ideally the default delay timing should be enough to ensure that the text appears.
I'm not currently working on fixing this issue, but calling it out as something we've seen in recent past. We've generally worked around this by simply spinning the runloop for a short bit before the view transitions, but this is a sharp corner we should try to avoid.