-
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
Allow for the browser caching of files during tests #18335
Comments
@mellis481 Did you figure something out about this problem? I'm having the same issue inside docker container 🤔 |
@alesbrelih Nope. |
@jennifer-shehane Are you able to speak to this topic? |
Came across this issue as well. My js bundles are identical and loading them is 80% of the test duration. |
Are there any recommended ways around this? We are also noticing that our Github actions cypress tests are slow and a great deal of the time is spent downloading assets over and over. |
When using Vite, you can use the following configuration to massively speed up your Cypress Component Tests:
Vite already uses this With this configuration, testing ~100 components went from taking 4-5 minutes on CI to 1 minute. Edit: This does not seem to work anymore with Cypress 10 though, which is quite frustrating. We can set the same options in |
@pmk1c Thanks for sharing. I had not come across Vite before. In the microfrontend ecosystem, each microfrontend does not have an *.html file (there is only one *.html file in the entire ecosystem). From what I was able to quickly read in their documentation, Vite is entirely based on the entry point being one or more *.html files so Vite will not work for single-spa-based microfrontends. |
My current understanding is that yes, it is the intended behavior. The way we more or less went around the issue for now is to call cy.visit() in our before() hook instead of a beforeEach(). We change the testIsolation parameter to false, and call the clear AllCookies/LocalStorage/AllSessionStorage functions manually in our before() function. This way, each time we run our spec file we make sure to have a clean browser session, but each test in the spec file uses the same browser window. It may not fit your need, our test are non-destructive and always ends up by testing if anything we triggered (like a pop-up) can be closed properly. |
Can you please provide a minimal example of where this is behaving unexpectedly? Cypress does not clear the browser cache between tests, only between specs, so it sounds like something else may be at play here. |
We also observe that. |
What would you like?
The ability to browser cache files in Cypress tests.
Why is this needed?
In applications that leverage the microfrontend architecture, each microfrontend has a single entry point (*.js file). In many cases, this single *.js file includes everything in that module and it can be somewhat large. Code splitting is possible, but it does not fully mitigate the problem described below.
An application that uses the microfrontend architecture relies heavily on browser caching. Each *.js file is versioned with a unique URL and has a
cache-control
header with a largemax-age
ie. it's browser cached for a long time. This means that the initial load time of a new version of a microfrontend is long, but subsequent loads in a browser are fast.Since browser caching files is not possible in Cypress tests, every Cypress test (
it
block) for a microfrontend has a long initial load time because it's downloading the *.js file in full and not retrieving it from browser cache. Having Cypress tests always taking a long time to execute is quite suboptimal.Other
No response
The text was updated successfully, but these errors were encountered: