-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
E2E Tests: Adding helpers to install/activate/deactivate and remove plugins #5906
Conversation
test/e2e/support/utils.js
Outdated
* | ||
* @return {Promise} Promise. | ||
*/ | ||
export async function waitForRequests( minDelay = 1000, maxDelay = 20000 ) { |
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.
This function is exactly the reason I loved Cypress. This was handled automatically. Can't find the equivalent in Puppeteer. This is trying to be as reliable as I can.
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.
While not intuitively named, I wonder if this is equivalent:
page.waitForNavigation( { waitUntil: 'networkidle0' } );
(There are various methods which have networkidle0
as well)
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.
Alternatively, instead of waiting for requests, you could wait for the DOM to be in a state you expect once the request completes:
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.
If anything, this highlights that Cypress gives us crutches to poor ways of expressing intent 😄
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.
If anything, this highlights that Cypress gives us crutches to poor ways of expressing intent
I don't agree with this, the idea in Cypress is when you do an action (click, move, anything) you wait for all the side effects to happen before continuing. I think it's great in terms of e2e maintainability.
page.waitForNavigation( { waitUntil: 'networkidle0' } );
This is not the same thing, this expects a page load and then waits for the network.
Alternatively, instead of waiting for requests, you could wait for the DOM to be in a state you expect once the request completes:
Yes, but this is not generic enough for me, we'd have to recreate the same thing over and over again because the UI change is not the same and also, sometimes there's no UI change, just a request that you need to wait for before quitting a page for instance which will cut the request.
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'm fine updating the PR to use selectors but I still disagree with you. Why waitForNavigation
exist in the first place, you could also replace it with waiting for UI
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.
What do you mean "waiting for UI" ? I am fine (enough) with methods like waitForSelector
.
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 was thinking: what's the difference between . page.waitForNavivation
and waitForRequests
there's none IMO, both are helpers to avoid the hassle of testing Async stuff.
Why would we be fine with waitForNavigation
and not waitForRequests
since both could be replaced with waitForSelector
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.
It depends in what context you mean to use waitForNavigation
.
If you mean for here, to wait for XHR requests to complete, then I would agree, it's no different and is not a good tool to use.
If you mean to its intended behavior to wait for a page to load, then I think it's slightly different since for a full page load, the user does use more of a judgment of network activity and page readiness to gauge when to continue (screen turns white, then loads). None of these are perfect, sure, and I suppose this is why Puppeteer provides options for waitUntil
, including load
, domcontentloaded
, networkidle0
, and networkidle2
.
But I do agree it's only slightly different. In reality, while page load process plays some role, in the end the user ultimately waits for the thing they expect to see on the page (waitForSelector
).
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 updated using waitForSelector
let me know what you think :)
For the purposes of testing extensibility APIs, I still think we should create isolated equivalent plugins housed in our own test suite instead of installing seemingly random plugins from WordPress.org. Ultimately, the challenge is that one of aforementioned seemingly random plugins could change anything at any point and cause the Gutenberg test suite to fail unexpectedly. |
We still need APIs to test installing plugins and we need APIs to activate/deactivate plugins (local or remote) so I I think this PR is still valuable. |
Fair enough. |
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.
Beautiful 👍
test/e2e/support/plugins.js
Outdated
*/ | ||
import { visitAdmin } from './utils'; | ||
|
||
export async function installPlugin( name, searchTerm ) { |
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.
What would be the purpose of the second argument here? Not clear by the included documentation 😉
test/e2e/support/plugins.js
Outdated
} ); | ||
await Promise.all( [ | ||
page.click( 'tr[data-slug="' + name + '"] .delete a' ), | ||
confirmPromise, |
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.
Not sure if it'll suffer the same race conditions as waitForNavigation
, but in that case, the suggested workaround has the "waiting" (event handler binding) arranged to take place before the click itself: https://github.com/GoogleChrome/puppeteer/blob/master/docs/api.md#pageclickselector-options
Nice 👍 It might be tricky to ensure that plugin gets properly uninstalled when the test fails because of random issues, but in general this will open a few interesting possibilities. 💯 |
In order to test extensibility APIs (meta boxes, templates etc...) we need a way to install and uninstall plugins.
This PR adds these helpers. I'm planning to use these in #5902
Testing instructions
You can add something like this to any e2e test