fast-check
fast-check copied to clipboard
Add package fast-check/vitest as a variation on the ava and jest integrations
🚀 Feature Request
Clear and concise description of the feature.
It'd be great to have an integration of fast-check into vitest since the interface you've built with those packages seems much clearer than trying to do so yourself.
I believe that you could easily modify the fast-check/jest package to achieve this?
Looks like you're already a bit on the way w/ your fork of vitest :p
Motivation
Please outline the motivation for the proposal.
Example
Please provide an example for how this feature would be used.
Yes, it's definitely an idea I'll have to investigate. I mostly moved back @fast-check/ava and @fast-check/jest into this monorepo to be able to unlock such need for other test frameworks. So definitely something planned with potentially jasmine, mocha, tape and vitest.
++ storybook-test https://storybook.js.org/docs/react/writing-tests/introduction/ / https://storybook.js.org/blog/interaction-testing-with-storybook/
though I'm still trying to figure out how that would work..
currently still enjoying vitest + fast-check + jest expect for this :)
glad to have caught a couple of edge-cases I wouldn't have otherwise!
Great to see fast-check is filling some of your needs. I have not taken the Vitest case into account yet, but given the current trend for this new test runner I'll probably deal with it soon or later. I'll just need to make my mind regarding what I want to deal with in those satellite packages. Today, they just bind fast-check with a test runner but are just simple syntax sugars, tomorrow they could leverage more of the framework they bind too like watch mode interaction...
yep it's working well :) the whole syntax and breadth of functions is pretty confusing to wade through, but now that I'm familiar with the project it's pretty powerful for improving the amount that I trust some of my utility functions.
Haven't really explored using this for UI bits like React components - storybook-test + miragejs generated content is mostly for that.
recent example of a fast check I built tho:
describe('validateDuration()', () => {
//... cut ...//
it('should accept valid durations (generated)', () => {
// an arbitrary that generates up to 500 spaces
const whitespace = fc.stringOf(fc.constantFrom(' '), { maxLength: 500 });
const validSeconds = fc.record({
number: fc.integer({ min: 1, max: 2 * 24 * 60 * 60 }),
whitespace,
unit: fc.constantFrom('s', 'sec', 'second', 'seconds'),
});
const validMinutes = fc.record({
number: fc.integer({ min: 1, max: 2 * 24 * 60 }),
whitespace,
unit: fc.constantFrom('m', 'min', 'minute', 'minutes'),
});
const validHours = fc.record({
number: fc.integer({ min: 1, max: 2 * 24 }),
whitespace,
unit: fc.constantFrom('h', 'hr', 'hour', 'hours'),
});
fc.assert(
fc.property(
// generate a valid input of a number, optional whitespace, and a valid unit of time
fc
.oneof(validSeconds, validMinutes, validHours)
.map(({ number, whitespace, unit }) => `${number}${whitespace}${unit}`),
fc.context(),
(text, ctx) => {
const output = mapStringToDurationOrOriginal(text);
ctx.log(output ?? '');
expect(validateDuration(output)).toBe(true);
}
)
);
});
});
@jasikpark FYI https://github.com/vitest-dev/vitest/discussions/2212
I just started to resurrect the PR I initially opened to create a dedicated package to bind fast-check to vitest as I do for jest and ava. The plan is to go for it.prop API as I recently proposed on jest side. The PR is not that far from being usable but before merging anything I need to add some tests on it. I hope to be able to have something soon.
In the meantime, I will try to get updates and feedbacks related the discussion opened on vitest's side. Ideally having such thing part of vitest would be even better.
wahoo! i've not felt too much pain using fast check w/ vitest without this integration, but it'll be very cool to have
i have semi frequently gotten segfaults from vitest watch + fast-check where a promise ends up panicking in v8 tho 😅
In theory if I succeed to push it as far as the one of jest, the runner should replace vitest to handle timeouts, leverage --seed if any can be defined via vitest (not sure vitest has such option ATM)... The first point about timeout is definitely game changer in such integration as it ensures execution of properties (assert as a whole not the single run) will not be too long as fast-check will abide by the timeout defined at jest/vitest level and stop runs as soon as the limit gets passed.
Regarding panics, feel free to report such cases if you find easily reproducible cases. I can attempt to check memory-wise (allocations) if something gets wrong on fast-check's side.
First version coming soon on @fast-check/vitest. But currently experiencing troubles with GH Actions making the release longer than expected 😊