Add XCUIElement helper methods to wait for an NSPredicate#6
Conversation
|
|
||
| public var description: String { | ||
| switch self { | ||
| case .completed: return "XCTWaiter.Result .completed" |
There was a problem hiding this comment.
Thanks to this extension when we print an XCTWaiter.Result value, it will print as the text defined here, as opposed to the current default "XCTWaiter.Result".
I bumped into this while debugging a test failure for this work.
I decided not to make this part of the framework to avoid clashing with other CustomStringConvertible conformances that a user of this library might have implemented.
| case .interrupted: return "XCTWaiter.Result .interruted" | ||
| case .invertedFulfillment: return "XCTWaiter.Result .invertedFulfillment" | ||
| case .timedOut: return "XCTWaiter.Result .timedOut" | ||
| @unknown default: return "XCTWaiter.Result unknown case – Please file a bug report at https://github.com/Automattic/XCUITestHelpers" |
There was a problem hiding this comment.
@unknonw default is a Swift that allows enum creators (in this case the Apple team that built XCTWaiter.Result to declare that there might be more cases added in the future and require consumers of the code to handle them somehow.
More details in the Swift feature proposal document.
| XCTAssertEqual( | ||
| app.staticTexts["a"].waitFor( | ||
| predicate: NSPredicate(format: "isEnabled == true"), | ||
| timeout: 2 // Interestingly, on Xcode 13.1, a 1 second timeout results in a failure | ||
| ), | ||
| .completed | ||
| ) | ||
| // Test the opposite scenario must also be true. | ||
| XCTAssertEqual( | ||
| app.staticTexts["a"].waitFor( | ||
| predicate: NSPredicate(format: "isEnabled == false"), | ||
| timeout: 2 | ||
| ), | ||
| .timedOut | ||
| ) |
There was a problem hiding this comment.
This approach of adding more assertions (examples) for a single unit of behavior is called triangulation.
One could argue that only having two examples doesn't really triangulate, but 🤷 : another example felt unnecessary.
|
I think this is a great addition to the framework! I executed the test app tests with no issues. But I can see the fails in related wordpress-mobile/WordPress-iOS/pull/17654, and they seem to happen on iPad only. Since they pass on iPhone, I tend to think that these fails should not be caused by the PR 🤔 |
|
One thing I didn't do is running wordpress-mobile/WordPress-iOS/pull/17654 locally. Will try this now. |
There was a problem hiding this comment.
While the tests from wordpress-mobile/WordPress-iOS/pull/17654 were failing on CI, I still could execute them (made sure that XCUITestHelpers dependency was really using the wait-for-predicate branch) locally on iPhone 13 and iPad (9th Gen) and they passed. Which means the fails are unlikely to be caused by this PR. 
|
Thanks @pachlava . I asked for a review before CI finished, whooops 🙃 The fact that UI tests on iPad failed on both Buildkite and CircleCI is not promising. I'll dig into it... |
Those failures were unrelated. Buildkite showed a weird behavior: It successfully retried a failing tests (via the Xcode Test Plan option), but reported the failure still 🤔 Here's the first failure.
And here's the successful retry
CircleCI experience a timeout trying to insert some text. I'm not sure what the issue was with that... Clearly yet another flaky test because it passed when I re-run the build 😞 |
2 participants
Making good on my promise to extract the code originally in WordPress iOS from this comment.
You can see it in action in WordPress iOS here.