-
-
Notifications
You must be signed in to change notification settings - Fork 3.1k
Closed as not planned
Labels
semver-majorimplementation requires increase of "major" version number; "breaking changes"implementation requires increase of "major" version number; "breaking changes"status: wontfixtypically a feature which won't be added, or a "bug" which is actually intended behaviortypically a feature which won't be added, or a "bug" which is actually intended behaviortype: discussiondebates, philosophy, navel-gazing, etc.debates, philosophy, navel-gazing, etc.type: featureenhancement proposalenhancement proposal
Description
I get sick of adjusting slow when adjusting timeout to avoid the warnings.
Unless slow is set by the user, what if we made it a function of the timeout value?
The current default values are 75ms for slow and 200ms for timeout. The function could be, then:
slow = timeout => 0.375 * timeout(If there's a different function that makes more sense, that'd be cool too)
I propose:
- If a user provides
--slow, that's the value we use. - If a user provides
--timeoutbut no--slow, we use the above function to determine the value ofslow - The equation is computed per-
Runnable. Meaning if we see athis.timeout(2000)(but importantly, nothis.slow(x)) in aRunnable, then we adjust theslowvalue using the function. - If the user provides
this.slow(x)in aRunnable, we use that value, otherwise we revert to whatever's used in the parent context. If it's set explicitly viathis.slow(x)in some parent context, use that; if it's set via--slowdo the same. If it's not set anywhere, use the function.
An alternative:
- If
slowis less than 1, it's no longer in milliseconds; it's considered a percentage of the value oftimeout. We could get away with shipping that in a minor
Thoughts? @mochajs/core
renataogarcia and hverlin
Metadata
Metadata
Assignees
Labels
semver-majorimplementation requires increase of "major" version number; "breaking changes"implementation requires increase of "major" version number; "breaking changes"status: wontfixtypically a feature which won't be added, or a "bug" which is actually intended behaviortypically a feature which won't be added, or a "bug" which is actually intended behaviortype: discussiondebates, philosophy, navel-gazing, etc.debates, philosophy, navel-gazing, etc.type: featureenhancement proposalenhancement proposal