如何将 cypress 与预取或预加载 webpack 的组件一起使用？

Question

I'm using Cypress 7.7.0 (also tested on 8.0.0 ), and I'm running into an interesting race condition. I'm testing a page where one of the first interactions that Cypress does is click a button to open a modal. To keep bundle sizes small, I split the modal into its own prefetched webpack chunk. My Cypress test starts with cy.get('#modal-button').click() but this doesn't load the modal because the modal hasn't finished downloading/loading. It does nothing instead (doesn't even throw any errors to the console). In other words, Cypress interacts with the page too quickly. This was also reproduced with manual testing (I clicked on the button super fast after page load). I have tried setting the modal to be preloaded instead, but that didn't work either.

I am able to solve the problem by introducing more delay between page load and button interaction. For example, inserting any Cypress command (even a cy.wait(0) ) before I click on the button fixes the solution. Cypress , however, is known for not needing to insert these brittle solutions. Is there a good way to get around this? I'd like to keep the modal in its own chunk.

FYI: I'm using Vue as my front end library and am using a simple defineAsyncComponent(() => import(/* webpackPrefetch: true */ './my-modal.vue')) to load the modal component. I figure that this problem is general to Cypress though.

Answer 1

There's nothing wrong with cy.wait(0) .

All you are doing is handing control from the test to the next process in the JS queue, in this case it's the app's startup script which is presumably waiting to add the click handler to the button.

I recently found that this is also needed in a React hooks app to allow the hook to complete it's process. You will likely also come across that in Vue 3, since they have introduced a hook-like feature.

If you want to empirically test that the event handler has arrived, you can use the method given here (modified for click() ) -When Can The Test Start?

let appHasStarted

function spyOnAddEventListener (win) {
  const addListener = win.EventTarget.prototype.addEventListener
  win.EventTarget.prototype.addEventListener = function (name) {
    if (name === 'click') {
      appHasStarted = true
      win.EventTarget.prototype.addEventListener = addListener  // restore original listener
    }
    return addListener.apply(this, arguments)
  }
}

function waitForAppStart() {
  return new Cypress.Promise((resolve, reject) => {
    const isReady = () => {
      if (appHasStarted) {
        return resolve()
      }
      setTimeout(isReady, 0)  // recheck "appHasStarted" variable
    }
    isReady()
  })
}

it('greets', () => {
  cy.visit('app.html', {
    onBeforeLoad: spyOnAddEventListener
  }).then(waitForAppStart)

  cy.get('#modal-button').click()
})

But note setTimeout(isReady, 0) will probably just achieve the same as cy.wait(0) in your app, ie you don't really need to poll for the event handler, you just need the app to take a breath.

Answer 2

It seems like your problem is that you're already rendering a button before the code backing it is loaded. As you noticed, this isn't only an issue for fast automated bots, but even a "regular" user.

In short, the solution is to not display the button early, but show a loading dialog instead. Cypress allows waiting for a DOM element to be visible with even a timeout option. This is more robust than a brittle random wait.

Answer 3

I ended up going with waiting for the network to be idle, although there were several options available to me.

The cypress function I used to do this was the following which was heavily influenced by this solution for waiting on the network :

Cypress.Commands.add('waitForIdleNetwork', () => {
    const idleTimesInit = 3
    let idleTimes = idleTimesInit
    let resourcesLengthPrevious

    cy.window().then(win =>
        cy.waitUntil(() => {
            const resourcesLoaded = win.performance.getEntriesByType('resource')

            if (resourcesLoaded.length === resourcesLengthPrevious) {
                idleTimes--
            } else {
                idleTimes = idleTimesInit
                resourcesLengthPrevious = resourcesLoaded.length
            }

            return !idleTimes
        })
    )
})

Here are the pros and cons of the solution I went with:

• pros: no need to increase bundle size or modify client code when the user will likely never run into this problem
• cons: technically still possible to have a race condition where the click event happens after the assets were downloaded, but before they could all execute and render their contents, but very unlikely, not as efficient as waiting on the UI itself for indication of when it is ready

This was the way I chose solve it but the following solutions would have also worked:

• creating lightweight placeholder components to take the place of asychronous components while they download and having cypress wait for the actual component to render (eg a default modal that just has a spinner being shown while the actual modal is downloaded in the background)
  • pros: don't have to wait on network resources, avoids all race conditions if implemented properly
  • cons: have to create a component the user may never see, increases bundle size
• "sleeping" an arbitrary amount (although this is brittle) with cy.wait(...)
  • pros: easy to implement
  • cons: brittle, not recommended to use this directly by Cypress, will cause linter problems if using eslint-plugin-cypress (you can disable eslint on the line that you use this on, but it "feels ugly" to me (no hate on anyone who programs that way)