-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Skip running TokenField tests by default #982
Conversation
For me, seven of the tests are marked by Mocha as "slow" when run locally, ranging from about 1-2.5s. |
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.
Agree we should stop these tests from running 'til we can resolve timeouts 👍
I am fully in favor of having all of our standard test suite execute in less than one second (after build time). However, it's a bit worrisome that these tests are enough to push our builds over the timeout limit. This must mean that we're already pretty close. I wonder how much upgrading to npm 5 would help with this. |
Are the tests using real |
I think it's just that jsdom is slow at emulating mouse and keyboard events (and that Travis is much slower than Circle CI, where these tests run today in Calypso). We're not using any timeouts in the tests.
Or were we running into the |
Follow-up to #924 (comment)
Even though these tests use
enzyme
, they look more like "integration tests" than "unit tests" and perhaps should not be run on every build. They might fit better in another category of tests (#939 (comment)), with a different strategy for running them (for example, executed every hour against themaster
branch).However,
TokenField
has a long history of weird bugs and these tests are pretty important to keep around in some form.Also worth noting that these tests execute far, far more quickly on my computer than they do on Travis. The slowest test when running locally was 639ms; on Travis this is more like 3 seconds.