✨ Bias towards extreme values for integer and bigint

[dubzzz]

In a nutshell

Up to now, when trying to bias generated values to fall quickly in classical corner cases, fast-check used to generate integer values close to zero. It did a quite nice job to find bugs in lots of programs. But most of the time when we build algorithms, we have bugs close to zero but also close to our boundaries (ie min and max values).

This new development tries to push bias to the next level: bias should not only find bugs related to small values but also the ones related to largest ones. When we say: our algorithm should work with integer value, fast-check should trust you and try any integer values including crazy ones like Number.MAX_SAFE_INTEGER if you said it worked for it too.

Next steps: In the future, arbitraries on strings (outside of this review) will also bias towards classical strings causing issues.

✔️ New feature
❌ Fix an issue
❌ Documentation improvement
❌ Other: please explain

(✔️: yes, ❌: no)

Potential impacts

Impact generated values of all the arbitraries of fast-check.

As integer is a root arbitrary for barely any of the arbitraries offered in fast-check, mos of the arbitraries will be impacted by this change (regarding generated values).

[codesandbox-ci]

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 93ac7a0:

Sandbox	Source
Vanilla	Configuration
fast-check-examples	Configuration

[coveralls]

Coverage decreased (-0.1%) to 96.318% when pulling 93ac7a0 on bias-towards-extreme-values into e5ad46b on master.