Cypress requires developers to have a mental model of "calling a Cypress function actually adds an action to the back of a queue and immediately returns control flow without waiting for that action to run." And this is fine if you can express your waits and conditions declaratively - you give Cypress a plan, it decodes the plan from your Cypress code in milliseconds, and then will take as long as it needs to execute that plan.
And Cypress gives a great API surface where almost everything can be done with just this declarative API, and it enables them to show the full plan in a UI even while it's executing.
But if you actually need custom control flow, with code you control... you need to "pause" your action-enqueueing to let Cypress catch up. Which means you're going to be nesting callbacks, or sprinkling awaits in all the places that aren't logically awaiting, because you need an explicit yield point out of your JS block. Our team finds this rare enough that it's acceptable. But... yeah, it's far from a perfect solution.
I’m using cypress now and finally grokked the queue notion. But cypress is still flaky: very frequently the first character typed into an input element is lost (Firefox). Switched from Chrome to Firefox because Chrome would run out of memory after too many tests.
Both of these issues are well documented in git issues with hundreds of replies and work arounds that just don’t always work.
I’m ready to throw in the towel and rewrite everything in playwright. Maybe b I’ll have different issues there…
I had this issue too, are you using React? The problem I was having was to do with React re-rendering out of step with Cypress (which was going *too* fast).
I have only seen this issue with JS based VDOM frameworks.
If I write the code “cy.wait(…); console.log(“hi”); cy.whatever()” then the “whatever” will indeed be queued to run after the network request completes. But “hi” will have printed immediately before any of this happens! So if that log was, say, me wanting to condition on something that just loaded, I can’t assume it’s even set up at that point when my JS code is executing!
And Cypress gives a great API surface where almost everything can be done with just this declarative API, and it enables them to show the full plan in a UI even while it's executing.
But if you actually need custom control flow, with code you control... you need to "pause" your action-enqueueing to let Cypress catch up. Which means you're going to be nesting callbacks, or sprinkling awaits in all the places that aren't logically awaiting, because you need an explicit yield point out of your JS block. Our team finds this rare enough that it's acceptable. But... yeah, it's far from a perfect solution.