Skip to content
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

Proposal: Cypress should preprocess all of the spec files once #2304

Closed
paulfalgout opened this issue Aug 8, 2018 · 6 comments
Closed

Proposal: Cypress should preprocess all of the spec files once #2304

paulfalgout opened this issue Aug 8, 2018 · 6 comments
Assignees
Labels

Comments

@paulfalgout
Copy link
Contributor

Current behavior:

In v3 for each spec file, the preprocessor is run which has costly overhead.

Desired behavior:

In v2 since all the tests were run at once there was a single larger preprocessor event. For large test suites running the preprocessor once is significantly faster overall, which is much more noticeable in CI environments than it was locally. If possible, I'd love to see the preprocessor run once and the test splitting to happen post processing rather than processing each spec during the run.

In the meantime I've resorted to serializing the tests myself when running on CI via:

describe('Integration Tests', function() {
    const req = require.context('./', true, /^(.*\.(js$))[^.]*$/i);
    req.keys().forEach(function(key) {
        req(key);
    });
});

This certainly reduces some of the features of the v3 dashboard, but reduces our run time by over half. I don't think we could upgrade to v3 without it.

Versions

Cypress v3, Travis-CI, Chrome/Chromium

@paulfalgout
Copy link
Contributor Author

related: #1879

@paulfalgout
Copy link
Contributor Author

Ok some logs/evidence:
Travis serialize run completed in 8 min 19 sec with 2 spec files (one of which imports 44 other spec files).
cypress:webpack get occurred 3 times: ci.js - 35s support/index.js - 25s unit.js - 13s
cypress:webpack get overhead ~ 73s
https://gist.github.com/paulfalgout/8693cbb8fab358f3cb95067fb2e95056

Normal v3 run completed in 18 min 28 sec with 45 spec files
cypress:webpack get occurred 46 times: first spec file - 34s, support/index.js - 27ms, 44 additional spec files - 12-13s
cypress:webpack get overhead ~590s

https://gist.github.com/paulfalgout/738a1a84d2eda1e701fcf87fa9f1fee8

However I think maybe the log names were misleading a bit.. looking at the cypress:webpack close it looks like those just reflect the test time and there's no closing anyhow since there's no watching going on.. so the logs are just logging what happened up until the event? So I initially thought the cost was webpack and the complexity of our build.. however I suspect the cypress:webpack get reflects events up until, but not including the preprocessor in which case I'm not sure what's adding the overhead, but hopefully it could be combined but still maintain the test run separation?

@paulfalgout
Copy link
Contributor Author

Might be what #2184 is doing

@paulfalgout
Copy link
Contributor Author

related #1915

@topheman
Copy link

I ended up doing something pretty similar: topheman/npm-registry-browser@4f7bcbe - though, I statically import the spec files. Your use of require.context is interesting on this use case.

@jennifer-shehane jennifer-shehane added type: performance 🏃‍♀️ Performance related stage: needs investigating Someone from Cypress needs to look at this labels Jan 28, 2019
@paulfalgout
Copy link
Contributor Author

I'm not doing this anymore. Other perf improvements plus various parallel functions makes this far less likely to be a thing I think.

@jennifer-shehane jennifer-shehane removed the stage: needs investigating Someone from Cypress needs to look at this label Jan 11, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants