Convert UI tests screens to be ScreenObject subclasses – Part 2 of many#17348
Convert UI tests screens to be ScreenObject subclasses – Part 2 of many#17348
ScreenObject subclasses – Part 2 of many#17348Conversation
|
You can trigger an installable build for these changes by visiting CircleCI here. |
|
You can trigger optional UI/connected tests for these changes by visiting CircleCI here. |
| let jetpackScan = mySite | ||
| .gotoJetpackScan() | ||
| let jetpackScan = try mySite | ||
| .goToJetpackScan() |
There was a problem hiding this comment.
Notice the camel case fix in the method: goto 👉 goTo. I've encountered a bunch of methods with goto and tackled them as part of the migration for the screen they belonged to.
| try FancyAlertComponent().acceptAlert() | ||
| case .cancel: | ||
| FancyAlertComponent().cancelAlert() | ||
| try FancyAlertComponent().cancelAlert() |
There was a problem hiding this comment.
I considered creating the FancyAlertComponent instance before the switch so that I could "reuse it" between cases. But, only one case runs at runtime, so there wouldn't have been any real benefit. Besides, the compiler might be doing other optimizations under the hood, too.
There was a problem hiding this comment.
Now that I've written this comment, though, I noticed that I could have done something like:
guard let alert = try? FancyAlertComponent() else { return self }
switch action {
case .accept: alert.acceptAlert()
...
🤔 I might do this in a followup...
| let supportScreen = try PrologueScreen().selectContinue().selectHelp() | ||
|
|
||
| XCTAssert(supportScreen.isLoaded()) | ||
| XCTAssert(supportScreen.isLoaded) |
There was a problem hiding this comment.
Reminder: ScreenObject has this as a computed variable instead of a function.
I did this to match the Swift APIs, e.g. Array isEmpty.
|
@pachlava I run out of time in my day to see this PR through in CI. It's possible the tests will fail due to some time outs. I think it's a mix of an issues that were there already my changes revealed and stuff I genuinely broke by changing some of the assumptions on which element is required to be available at some point in time. In my long running WIP branch, I have a few fixes that I might apply if that happens: |
_How did this work before?_
mokagio
force-pushed
the
convert-to-screen-objects-p2
branch
from
ecc6a2a to
e15ef94
Compare
That's because, before a valid email is insert, the continue button is disabled, which fails the tests.
| public class GetStartedScreen: ScreenObject { | ||
|
|
||
| private let navBarGetter: (XCUIApplication) -> XCUIElement = { | ||
| $0.navigationBars["Get Started"] |
There was a problem hiding this comment.
Note that this was "WordPress.GetStartedView" before. I'm not sure how the tests passed, because this version can't find this view. The string also don't appear in this repo or in the authenticator pod. 🤔 Maybe the element was created but never accessed?
There was a problem hiding this comment.
I think this is the case.
pachlava
left a comment
pachlava
left a comment
There was a problem hiding this comment.
I've executed the UI tests locally (passed), and also took a closer look into each changed file in Xcode, if it was about more than addition of throws / try - and noticed no issues. With auto-merge enabled, giving it an approval now 🚀. Thank you, Gio!
2 participants
Continues the work started in #17221. Refer to that PR for extra context on the structure of a
ScreenObjectsubclass.Regression Notes
Potential unintended areas of impact
N.A.
What I did to test those areas of impact (or what existing automated tests I relied on)
N.A.
What automated tests I added (or what prevented me from doing so)
N.A.
RELEASE-NOTES.txtif necessary. N.A.