-
-
Notifications
You must be signed in to change notification settings - Fork 182
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
Integrate jest timeouts to @fast-check/jest #3084
Comments
Definitely something to that could be interesting. fast-check's already receives a time-out as part of its options, it could either leverage it to set the one of jest or the opposite. |
If I'm using the jest package, how does the Like if Then if I use |
So far: // in jest.setup.cjs
fc.configureGlobal({timeout: 4000});
// alternatively: fc.configureGlobal({timeout: 4000, interruptAfterTimeLimit:4000, markInterruptAsFailure: false});
jest.setTimeout(5000) |
Probably one of the next feature I'm gonna to tackle |
In the context of #3084, we want to have a way built-in in fast-check to make sure that tests do not run for too long and can abide by certain timeouts constraints requested by the users. While today we do have a timeout, it only scopes the interruption to one run of the predicate but does not consider "the runs" as a whole contrary to `interruptAfterTimeLimit`. On the other hand, `interruptAfterTimeLimit` does have a timeout like behaviour but once started the predicate is never interrupted. Now it could be interrupted in-between, if running it until the end would cause a timeout given the time constraint passed to `interruptAfterTimeLimit`. With such new feature in place, we will probably have to consider properties not having run at least once as failure, otherwise a buggy async algorithm would be marked as failure if it led to timeout at first run with `interruptAfterTimeLimit`.
* ✨ Interrupt predicates when `interruptAfterTimeLimit` In the context of #3084, we want to have a way built-in in fast-check to make sure that tests do not run for too long and can abide by certain timeouts constraints requested by the users. While today we do have a timeout, it only scopes the interruption to one run of the predicate but does not consider "the runs" as a whole contrary to `interruptAfterTimeLimit`. On the other hand, `interruptAfterTimeLimit` does have a timeout like behaviour but once started the predicate is never interrupted. Now it could be interrupted in-between, if running it until the end would cause a timeout given the time constraint passed to `interruptAfterTimeLimit`. With such new feature in place, we will probably have to consider properties not having run at least once as failure, otherwise a buggy async algorithm would be marked as failure if it led to timeout at first run with `interruptAfterTimeLimit`. * versions * Add tests * add tests * Revert "Add tests" This reverts commit 14fb071.
🚀 Feature Request
Jest tests themselves have a timeout. It would be nice if these timeouts that are added into the
testProp
was used for fast check's timeout.Motivation
This makes it easier to know that the fast check
interruptAfterTimeLimit
will be always be under the timeout given to the full jest test itself. I suggest that it may need to be the jest timeout minus 1 second.Example
The
5000
should then be used for theinterruptAfterTimeLimit
.The text was updated successfully, but these errors were encountered: