-
Notifications
You must be signed in to change notification settings - Fork 3.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
Please make wait retry #26675
Labels
Comments
Somewhat related to #24164 |
nagash77
added
type: feature
New feature that does not currently exist
E2E
Issue related to end-to-end testing
labels
May 5, 2023
I managed to do it this way. Notice that I'm using cy.get instead of cy.wait.
|
I managed to do something similar by only waiting for the request I need: cy.intercept('GET', '/path/to/resource', req => {
if (!ctx.id) return;
req.alias = `alias-${ctx.id}`;
});
cy.wrap(ctx).then(() => {
// Calling this in .then ensures id is set to what I need at this point.
cy.wait(`@alias-${ctx.id}`)
.its('response.body')
.then($body => {
expect($body).not.to.be.undefined;
});
}); See also: #16321 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
What would you like?
I would like
wait
to retry.Why is this needed?
In my case I intercept every request and check if it is a graphQL request and if it is I pull out the mutation name and alias the request using that. Then in my tests I can, with no extra setup, wait for a particular mutation. What I also want to do is wait for certain mutations and then if that mutation contains a particular value I will proceed. For example we have an auto save feature on our forms which has a bunch of debouncing etc. This means that the number of requests that actually get sent are not relevant, I just need to wait until a particular mutation with the field I care about gets saved. In this specific test I am checking that I can resume from an autosaved state. If I don't wait then I can't tell if I am resuming before or after the autosave I am interested in occurred. If I had to wait for a certain number of requests to occur then the test would be overspecified and extremely brittle (if the number of requests is even deterministic). I'm going to have to duplicate my interception logic within each test and give it some other unique alias.
Other
wait
automatically increments so retrying makes a lot of sense.Alternatively I would like to be able to make any command retry even
then
via an option.The text was updated successfully, but these errors were encountered: