-
Notifications
You must be signed in to change notification settings - Fork 1k
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
More clearly explain that cypress commands are not promises #4148
Conversation
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.
@BlueWinds The heat death of the universe...heh...we have gotten commentary on this section before. I would say this is a bit outside of what our tone has become over the years so I'd be ok with removing it.
For the promise stuff, I feel like we should just not even be mentioning the word promise here at all and just describe it more plainly for what it is, a command queue. Once we associate it with the word Promise at all then we have to spend the rest of the time explaining why it's not. These 2 sections could probably use a restructure overall. It's very old.
That's a very good point. I've taken a more aggressive pen the wording of these sections - I think they're a bit more concise now, and address more directly a new developer's interest and concern with how cypress commands work and why they have certain limitations. A fair bit shorter than what was there before, but I don't think important information has been lost in the removals. |
ends up being non-deterministic. This means different test runs may behave | ||
differently, which makes them less deterministic and consistent. In general, | ||
there are only a handful of very specific situations where you _can_ | ||
create control flow using Cypress commands. |
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.
is this actually specific to Cypress?
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 might be misunderstanding what you mean, but the way cypress discourages catching errors - and even having if/then statements - does seem pretty unique.
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.
👍🏻 looks good to me.
Co-authored-by: Emily Rohrbough <emilyrohrbough@users.noreply.github.com>
When getting familiar with the product, this section of the documentation struck me as confusing, and after learning more about Cypress, I realized it was - while perhaps not technically incorrect - at least misleading.
Having a section "Cypress commands are promises" followed by an explanation of how they're not promises is rather strange.
For the removed part of the Conditional Testing guide, it was another of of perhaps being technically correct, but in fact being unconvincing and at least a little condescending. The prose here is improved by brevity.