✅ Clarify arbitrary benchmark names#7064
Merged
Merged
Conversation
|
@fast-check/ava
fast-check
@fast-check/jest
@fast-check/packaged
@fast-check/poisoning
@fast-check/vitest
@fast-check/worker
commit: |
dubzzz
enabled auto-merge (squash)
June 9, 2026 21:58
Contributor
⏱️ Benchmark ResultsClick to expand |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
This PR refines the names (and a few of the inputs) of the arbitrary generation benchmarks in
packages/fast-check/test/bench/arbitraries.bench.tsso the benchmark report is self-explanatory. There is no change to shipped library code — this only touches the benchmark suite, so end users see no behavioral difference; the benefit is for anyone reading benchmark output or adding new cases.Changes:
constantFrom(...)→constantFrom(1, 2, 3), with the case now usingfc.constantFrom(1, 2, 3)instead of the opaque'a'..'e'so the name matches what is benchmarked.constant(1)case (fc.constant(1)), which was previously missing, placed right beforeconstantFrom.integer().filter(.)→integer().filter(true), using a trivially-truthy predicate() => trueso the benchmark measures the filter wrapper overhead rather than a rejection-heavy predicate.integer().map(.)→integer().map(value*2), with the mapper changed to(n) => n * 2so the name reflects the operation.integer().chain(.)→integer().chain(integer()), making it explicit that the chain produces anotherfc.integer().Why
The previous names (
constantFrom(...),.map(.),.chain(.),.filter(.)) were placeholders that didn't convey what each case exercised, which makes benchmark diffs harder to interpret. The new names spell out the inputs/operations, and thefilter(true)predicate avoids letting rejection rate distort the measurement of the operator overhead itself.Scope & impact
Patch-level, benchmark-only, single concern. No production code is affected and no new public behavior is introduced. These are the bench definitions themselves, so they act as their own "tests"; the suite was type-checked to confirm the changes compile.
Checklist
— Don't delete this checklist and make sure you do the following before opening the PR
pnpm run bumpor by following the instructions from the changeset bot🐛(vitest) Something...) when the change targets a package other thanfast-checkGenerated by Claude Code