-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[UI Tests] Minor UI Tests code refactoring. #18349
Conversation
📲 You can test the changes from this Pull Request in WordPress by scanning the QR code below to install the corresponding build.
|
📲 You can test the changes from this Pull Request in Jetpack by scanning the QR code below to install the corresponding build.
|
// We're not running Stats tests for JP. | ||
// See https://github.com/wordpress-mobile/WordPress-Android/issues/18065 | ||
assumeTrue(!BuildConfig.IS_JETPACK_APP) | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When it was in the original place, the test was skipped for JP, as it should be, but setUp
was still executed, which took ~20 seconds. Since there's only one test in this class, keeping it here does not affect any other tests.
if (isElementDisplayed(R.id.continue_with_wpcom_button) || isElementDisplayed(R.id.login_open_email_client)) { | ||
return; | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The removed code didn't add much value, IMO, removing it changes nothing in the logic, and it also means two checks less. The method will still logout only if it sees the navbar.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can't help but wonder why this was added in the first place, the only reason i could think of is some potential speed improvements (not sure how much though, if any). but looking at it, i would agree with you that it doesn't seem to add much value
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I assume the logic behind this was "firstly, escape the function if we are already in the logged out state". But it turned out that it's faster to check that we are in the logged in state.
val negativeButton = | ||
Espresso.onView(ViewMatchers.withId(R.id.quick_start_prompt_dialog_button_negative)) | ||
WPSupportUtils.waitForElementToBeDisplayed(negativeButton) | ||
WPSupportUtils.clickOn(negativeButton) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
clickOn
already contains waitForElementToBeDisplayed
, so it was redundant here. Also, I went for passing the identifer to the function, instead of the ViewMatcher, to keep it shorter.
@@ -32,7 +32,6 @@ class BlockEditorTests : BaseTest() { | |||
fun e2ePublishSimplePost() { | |||
val title = "publishSimplePost" | |||
MySitesPage() | |||
.go() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After login, the app is already in needed section, no need to go there again.
|
||
@After | ||
fun tearDown() { | ||
logoutIfNecessary() | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Every setUp
method (for all tests) contains logoutIfNecessary
, so I saw no value in also having a teardown that does the same.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
usually the "clean up" happens after the test ends, curious to know your reason for keeping the one in setUp()
instead of tearDown()
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd advocate that every test is responsible for setting up the right environment before it starts, and not when it ends. Thus from my experience, it's always more resilient to handle prerequisites in setUp.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Only LoginTests.kt
and SignUpTest.kt
contained both setUp
and teardDown
with logoutIfNecessary
, while the remaining five files contain only setUp
with logoutIfNecessary
. I removed the ones from tearDown
because of a smaller footprint.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i've personally used both setUp()
and tearDown()
to "clean up" test states, depending on what it does and what the end states of the tests are. in the case where we are deleting the app (what JPiOS is doing), it would make sense to do it during tearDown()
and from your reasoning for this one, this change makes sense to me since it was already in setUp()
in the other files 👍
// We run the class for JP only (so far the class contains | ||
// only a test for Domains card, which in not valid for WP) | ||
assumeTrue(BuildConfig.IS_JETPACK_APP) | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All changes in this file is a cherry-pick from #18349
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
did you mean to link to a different PR/commit? currently that link is this PR
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, sorry, I meant #18365
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I meant #18365
Are you sure? That PR wasn't yet merged.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks for making these updates and removing those unnecessary lines @pachlava! since this involves multiple tests, i'm depending on the CI results for this.
the only outstanding question i have is on the position of logoutIfNecessary()
, the other changes look good to me!
// We run the class for JP only (so far the class contains | ||
// only a test for Domains card, which in not valid for WP) | ||
assumeTrue(BuildConfig.IS_JETPACK_APP) | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
did you mean to link to a different PR/commit? currently that link is this PR
|
||
@After | ||
fun tearDown() { | ||
logoutIfNecessary() | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
usually the "clean up" happens after the test ends, curious to know your reason for keeping the one in setUp()
instead of tearDown()
?
if (isElementDisplayed(R.id.continue_with_wpcom_button) || isElementDisplayed(R.id.login_open_email_client)) { | ||
return; | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can't help but wonder why this was added in the first place, the only reason i could think of is some potential speed improvements (not sure how much though, if any). but looking at it, i would agree with you that it doesn't seem to add much value
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
CI is ✅
Description
While dealing with recent increase in UI tests fails on FTL, I firstly started looking into the tests code to search for possible improvements. The flakiness was caused by FTL service disruption, however, the changes I made to the code still make sense, IMO.
(This is also an explanation for the misleading branch name).
Each change was made in a separate commit, so it can be reverted, if you find this necessary. I recommend reviewing this PR by looking into commits separately.
Testing