Who's using fast-check? 🤔

[dubzzz]

As maintainer of fast-check I would be really interested to know who — individuals, companies or open source projects — is using fast-check? For which needs? And eventually the benefits of using it?

[dan-blank]

[Individual] I try out fast-check in my free time and want to propose its use in my working place when I feel confident enough to present it. My hope is that it catches bugs in web applications with complex business logic that otherwise would slip through (pretty much the vanilla use case).

[dubzzz]

[Company] At Pigment (website/GitHub), we use it on all our Pull Requests. It has been introduced quite early in our testing stack and was able to detect problems before we released features to production. It has been useful on various parts of our front (in React): from core algorithms, to invariants on components, but also in things like detection of race conditions.

Here are some examples of our usages:

• Rendering of pivoted tables: In Pigment, tables are virtualized for performance reasons. Indeed they may contain thousands and even millions of lines so we don't want to render them all together. As a consequence most of the rendering is handled through div elements absolutely placed. We use property based testing to ensure that whatever the inputs (valid) we pass to our table the resulting DOM will always be a rectangular area with no overlapping between cells (combined with react-testing and jest-dom).
• Subscribers to back-end services: Components are offered a way to communicate and watch updates coming from the back. From time to time the updates need an explicit subscription message toward the back but also an unsubscription one. The front deals with pools of registered entities and emit messages toward the back whenever needed: send a subscription whenever the subscriber is the first one for this precise event and an unsubscription whenever it is the last one to disconnect. As a consequence, because everything is asynchronous by nature, we have potential race conditions in mind while working on this part. In order to prevent some to appear we use the scheduler feature of fast-check and check that subscriptions are sent in-time and unsubscriptions too.
• ...many other places: From algorithms converting back data to front and vice-versa to algorithms transforming structures for optimized look-up and traversal...

Setup:

• We always run them with different seeds in the CI and locally. In other words we never specify the seed.
• We globally define a time limit for property based tests using fc.configureGlobal({ interruptAfterTimeLimit: 500 }) in order to avoid tests from taking too long. The main motivations behind that one were 1) tests of components take long 2) in case of bug, the shrinker may take some time to shrink so we prefer running the shrinking part locally in order to avoid wasting CI time if the shrinking process is too long.

Did it find bugs?:
Yes! Many times and even when example-based coverage looked well: it helped us to avoid releasing partially broken features.

[krisanselmo]

[Company] We use fast-check At Myre (website). Especially in our shared engine repository which have abstract/core algorithms and common interfaces/helpers between backends & frontends (all full typescript). To not impact the developer experience, we have separated stages of example based testing (less than 5 sec) and property based testing (~35 sec). Our CI runs both on every pull request on this repo. It helps us to early detect edge cases and bullet proof some complex features. On top of that, we also reuse generated arbitraries to do test fuzzing on our APIs.

[Vinnl]

I've introduced it to @inrupt/solid-client. The primary use case is for code related to access control, to try to detect situations in which we might cause privilege escalation. It helped us detect and cover a couple of edge cases!

[jasikpark]

Using it for a couple of unit tests at work, but I haven't attempted to use it for react component tests...

We use storybook and storybook-test for most of our UI-based interaction tests and I haven't sorted out how to integrate fast-check into that setup v.s. just using minifaker to generate data for our tests, and asserting that a form completes or errors with the right values...

It's hard to think how you can do more than unit test with fast-check honestly

[jasikpark]

I'll definitely play around with the jest integration as I work through the testing portion of https://epicreact.dev though!

[gruhn]

I work for a machine translation company called DeepL. The main product is two text boxes where users can translate free text into different languages. There is a lot of complicated stuff going on in these innocent looking text boxes (in the frontend alone), in particular because users can edit both the source text and the translated text, and the fuzzy relationship between the two must constantly be maintained. I use fast-check extensively to hunt down edge cases there. And I think together with the type checker it's really the strongest verification tool (that is still ergonomic) in the entire ecosystem.