-
-
Notifications
You must be signed in to change notification settings - Fork 186
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
✨ Add ability to limit shrink path #5006
Conversation
Related to #4162
This pull request is automatically built and testable in CodeSandbox. To see build info of the built libraries, click here or the icon next to each commit SHA. Latest deployment of this branch, based on commit dd752cb:
|
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #5006 +/- ##
==========================================
+ Coverage 96.89% 96.90% +0.01%
==========================================
Files 215 218 +3
Lines 16384 16533 +149
Branches 2670 2703 +33
==========================================
+ Hits 15875 16022 +147
- Misses 509 511 +2
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
👋 A preview of the new documentation is available at: http://667d1456a4794187f64145a3--dubzzz-fast-check.netlify.app |
👋 A preview of the new documentation is available at: http://6687fae2757d6a6f1c407228--dubzzz-fast-check.netlify.app |
Description
We want to offer a way for our users to limit the depth and overall size of the shrinking capabilities. At the moment, they can only either apply shrink or drop it totally. We want to offer a finer way to control the shrinks.
This proposal is related to #4162.
At the moment, we added an extra method for all our arbitrary but I feel that it will not be scalable. I believe we should go for yet another utility arbitrary that will be responsible to offer such capabilities. Regarding offering these capabilities at assert level itself, we should probably (option 1) do as we used to do for timeouts..., or (option 2) start thinking into some kind of plugin system. Option 1 seems to be a valid option for version 3 of fast-check, we could also start offering a noShrink utility either hidden behind limitShrink one (probably better) or directly.
NOTE: Not ready yet, we should move from methods to a dedicated utility.
Checklist — Don't delete this checklist and make sure you do the following before opening the PR
yarn bump
and flag the impacts properlyAdvanced