diff --git a/website/blog/2023-05-21-whats-new-in-fast-check-3-9-0/index.md b/website/blog/2023-05-21-whats-new-in-fast-check-3-9-0/index.md index 93b00beb..6a312ac8 100644 --- a/website/blog/2023-05-21-whats-new-in-fast-check-3-9-0/index.md +++ b/website/blog/2023-05-21-whats-new-in-fast-check-3-9-0/index.md @@ -122,7 +122,7 @@ test('should update to the value of the last promise', async () => { This snippet specifies how to wrap each `Promise` when defining it. It lets the author of the test the ability to define for each scheduled task how to wrap it. -:::tip Alternative with act at wait level +:::tip[Alternative with act at wait level] Instead of specifying for each scheduled task how to wrap it, we can wrap them all the same way by passing the `act` function at wait time. In order to do that, we mostly have to replace: - `s.schedule(..., undefined, undefined, act)` by `s.schedule(...)`, @@ -130,11 +130,11 @@ Instead of specifying for each scheduled task how to wrap it, we can wrap them a ::: -:::warning Alternative with act at scheduler level +:::warning[Alternative with act at scheduler level] While it was the only approach available in the past, we now recommend users to adopt the usage of `act` at either the wait level or the scheduling level. Defining `act` on `fc.scheduler` is not optimal when it comes to custom manual examples, as it would require passing the custom `act` to the manually created instances of `fc.schedulerFor` as well (supported but easy to forget). ::: -:::tip Not restricted to React +:::tip[Not restricted to React] The `act` pattern is not restricted to React. While it was initially designed for React, it can be highly beneficial whenever you need to encapsulate calls and introduce a specific context around them. For example, we used it to manipulate timers in the new documentation, as demonstrated in [the section on scheduling native timers](/docs/advanced/race-conditions/#scheduling-native-timers). ::: diff --git a/website/blog/2023-05-30-whats-new-in-fast-check-3-10-0/index.md b/website/blog/2023-05-30-whats-new-in-fast-check-3-10-0/index.md index f9eb84b9..2d00ac30 100644 --- a/website/blog/2023-05-30-whats-new-in-fast-check-3-10-0/index.md +++ b/website/blog/2023-05-30-whats-new-in-fast-check-3-10-0/index.md @@ -32,13 +32,13 @@ const ipV4Arbitrary = fc.stringMatching( By leveraging the `stringMatching`, users can now easily define string patterns that conform to specific rules or formats. It should reduce the learning curve associated with custom string value generation. -:::info Don't forget `^` or `$` +:::info[Don't forget `^` or `$`] By default, the `stringMatching` arbitrary generates strings that match the provided regular expression. It's important to note that if you don't include the `^` (start of string) or `$` (end of string) assertions in your regex, the generated string may contain more characters than expected. In the example above, we explicitly included the `^` and `$` assertions in our regex to ensure that the generated values strictly restrict to an IP v4. Without these assertions, the arbitrary could have produced strings like `a(g{{jzerj1.90.1.1dfiosr`. Therefore, when using `stringMatching`, remember to include `^` at the beginning and `$` at the end of your regex if you want to avoid generating values that start with unrelated characters. ::: -:::warning Partial support +:::warning[Partial support] Please note that while JavaScript regular expressions allow for the definition of complex constraints on strings, our current implementation in fast-check has some limitations in handling certain regex features. Specifically, the following constructs are not supported: `\b`, `\B`, `(?=`, `(?!`, `(?<=`, `(? { }); ``` -:::info Shrink or no shrink? +:::info[Shrink or no shrink?] As shrinking the seed does not provide any value in terms of the shrinker, we wrapped our seed generator within `fc.noShrink(...)`. Shrinking only makes sense if it simplifies the produced values. By shrinking the seed, we have no guarantee that we will reach a simpler value. As such, we dropped the shrinking capabilities for `fakerToArb`. ::: @@ -172,7 +172,7 @@ class FakerFirstNameBuilder extends fc.Arbitrary { Shrinking capabilities primarily depend on the `shrink` method of `FakerFirstNameBuilder`. -:::info What about others? +:::info[What about others?] It's important to note that attributing shrinker capability solely to the `shrink` method is a simplification. All methods within an Arbitrary instance work together to provide effective shrinking. @@ -236,7 +236,7 @@ class FakerFirstNameBuilder extends fc.Arbitrary { } ``` -:::tip `fc.string()` might not be ideal +:::tip[`fc.string()` might not be ideal] While the previous implementation is functional, users might have requirements to exclude certain characters from generated strings. Therefore, `fc.string()` might not be optimal since it could potentially shrink a first name to include non-alphabetic characters. An alternative approach could involve using `fc.stringOf(...)` to better control the character set allowed in generated strings. ::: diff --git a/website/docs/advanced/fake-data.md b/website/docs/advanced/fake-data.md index b2b13c1c..7bea9e75 100644 --- a/website/docs/advanced/fake-data.md +++ b/website/docs/advanced/fake-data.md @@ -95,7 +95,7 @@ For example, while an IPv4 address may be commonly represented as something like However, fast-check does not currently provide generators for names, surnames, or other non-fully constrained values. It is up to the user to provide their own generators for such data types. -:::tip Build your own arbitraries +:::tip[Build your own arbitraries] If you need to generate custom fake data, such as names and surnames, you can refer to fast-check's [combiners](/docs/core-blocks/arbitraries/combiners/any/), which are designed to allow users to create their own values according to their specific needs. ::: @@ -103,11 +103,11 @@ If you need to generate custom fake data, such as names and surnames, you can re In order to integrate external fake data libraries with fast-check, the generators have to be wrapped as arbitraries. -:::warning Minimal requirements +:::warning[Minimal requirements] The minimal requirement that needs to be fulfilled by the wrapped library is to provide a way to be seeded and reproducible. fast-check cannot offer replay capabilities if the underlying generators are not able to generate the same values from one run to another. ::: -:::warning Limitations +:::warning[Limitations] Please note that if not explictely defined, the arbitraries will not be able to shrink the generated values. ::: @@ -140,7 +140,7 @@ const streetAddressArb = fakerToArb(faker.address.streetAddress); const customArb = fakerToArb(() => faker.fake('{{name.lastName}}, {{name.firstName}} {{name.suffix}}')); ``` -:::tip Recommended integration for Faker +:::tip[Recommended integration for Faker] Our recommended integration for Faker has changed since the release of the version 8.2.0 of Faker. We recommend you to have a look to [our article](/blog/2024/07/18/integrating-faker-with-fast-check/) on the subject. ::: diff --git a/website/docs/advanced/fuzzing.md b/website/docs/advanced/fuzzing.md index 9538f803..97dfa2f3 100644 --- a/website/docs/advanced/fuzzing.md +++ b/website/docs/advanced/fuzzing.md @@ -24,7 +24,7 @@ For instance, if you intend to run the tests an infinite number of times, you ca fc.configureGlobal({ numRuns: Number.POSITIVE_INFINITY }); ``` -:::warning Multi-process +:::warning[Multi-process] Please note that if you intend to run multiple properties an infinite number of times, it may be necessary to run them via multiple processes. JavaScript being a single-threaded language, running multiple infinite loops in a single thread may result in only one property being executed. Therefore, to avoid this limitation and ensure that all properties are executed as intended, you should consider running them in separate processes. diff --git a/website/docs/advanced/index.md b/website/docs/advanced/index.md index e03e54d9..5891aeec 100644 --- a/website/docs/advanced/index.md +++ b/website/docs/advanced/index.md @@ -15,7 +15,7 @@ Each page solves a different class of problem that cannot be expressed cleanly a - **Fuzzing** — when you want to keep hunting for counterexamples across runs or beyond the default budget, turning fast-check into a continuous fuzz loop rather than a CI gate. - **Fake data** — when you need large volumes of realistic-looking values outside the property-test context, for seeding environments or staging datasets. -:::tip Want a hands-on walkthrough on race conditions? +:::tip[Want a hands-on walkthrough on race conditions?] [Race conditions](/docs/advanced/race-conditions/) is the reference. If you would rather learn by writing a failing test step by step, the [Detect race conditions tutorial](/docs/tutorials/detect-race-conditions/) covers the same ground interactively. ::: diff --git a/website/docs/advanced/model-based-testing.md b/website/docs/advanced/model-based-testing.md index 9b52b3ef..1598e40d 100644 --- a/website/docs/advanced/model-based-testing.md +++ b/website/docs/advanced/model-based-testing.md @@ -10,13 +10,13 @@ Turn fast-check into a crazy QA Model-based testing can also be referred to as [Monkey testing](https://en.wikipedia.org/wiki/Monkey_testing) to some extent. The basic concept is to put our system under stress by providing it with random inputs. With model-based testing, we compare our system to a highly simplified version of it: the model. -:::info The model, an optional helper +:::info[The model, an optional helper] While the model part can assist you in writing your tests by storing intermediate states, past actions, or even mimicking the system, it is entirely optional. Model-based testing can be performed without it as well. ::: In the context of fast-check, model-based testing involves defining a set of commands that can be seen as potential actions to be executed on your system. Each command consists of two elements: a check to verify if the action can be executed in the current context, and the action itself, which also performs assertions. Typically, we rely on the model to verify if the action is suitable and apply the action to both the system and the model. -:::warning The model, a simplified version of the system +:::warning[The model, a simplified version of the system] Although the model can be a useful tool, it's important to use it carefully. Model's goal is to simplify the system, but there is a risk that it may mimic the system too closely, leading to errors. The model should not be a carbon copy of the system but a simplified representation of it. It's crucial to avoid testing the code by comparing it to itself. ::: @@ -30,7 +30,7 @@ In fast-check, the commands have to implement the interface [`ICommand`](/docs/a - `run(model, real)` — Execute the action - `toString()` — Serialize the command for error reports -:::tip Example of commands +:::tip[Example of commands] If your system is a music player, here are some commands you may have: play, pause, next track, add track… ::: @@ -38,7 +38,7 @@ If your system is a music player, here are some commands you may have: play, pau Then, to ingest your previously defined commands into fast-check as an arbitrary, you can use the [`commands`](/docs/api/functions/commands) arbitrary. This function takes an array of commands as input and compiles them to produce a scenario that can be applied to your system. -:::info Isn't commands just an array builder? +:::info[Isn't commands just an array builder?] Yes and no! - Yes, because `commands(myCommands)` could be mimicked by `array(oneof(...myCommands))`. @@ -191,7 +191,7 @@ fc.assert( ); ``` -:::info Why is there something specific to do for commands? +:::info[Why is there something specific to do for commands?] In order to come with a more efficient shrinker, `commands` takes into account the commands that have really been executed. Basically if the framework generated the following commands `[A,B,C,A,A,C]` but only executed `[A,-,C,A,-,-]` it will shrink only `[A,C,A]`. The value stored into `replayPath` encodes the history of what was really executed in order not re-run any intermediate step on replay. diff --git a/website/docs/advanced/race-conditions.md b/website/docs/advanced/race-conditions.md index 6f730b7b..b232d32c 100644 --- a/website/docs/advanced/race-conditions.md +++ b/website/docs/advanced/race-conditions.md @@ -53,7 +53,7 @@ On its side the scheduled `Promise` will only resolve when the scheduler decides Once scheduled by the scheduler, the scheduler will wait the wrapped `Promise` to resolve before sheduling anything else. -:::warning Catching exceptions is your responsability +:::warning[Catching exceptions is your responsability] Similar to any other `Promise`, if there is a possibility that the wrapped `Promise` may be rejected, you have to handle the output of the scheduled `Promise` on your end, just as you would with the original `Promise`. ::: @@ -113,7 +113,7 @@ scheduleFunction: (asyncFunction: (...args: TArgs) => Pr Any algorithm making calls to asynchronous APIs can highly benefit from this wrapper to re-order calls. -:::warning Only postpone the resolution +:::warning[Only postpone the resolution] `scheduleFunction` is only postponing the resolution of the function. The call to the function itself is started immediately when the caller calls something on the scheduled function. ::: @@ -145,7 +145,7 @@ await s.waitNext(1); Create a sequence of asynchrnous calls running in a precise order. -:::info While running, tasks prevent others to complete +:::info[While running, tasks prevent others to complete] One important fact about scheduled sequence is that whenever one task of the sequence gets scheduled, no other scheduled task in the scheduler can be unqueued while this task has not ended. It means that tasks defined within a scheduled sequence must not require other scheduled task to end to fulfill themselves — _it does not mean that they should not force the scheduling of other scheduled tasks_. ::: @@ -164,7 +164,7 @@ scheduleSequence(sequenceBuilders: SchedulerSequenceItem[], customAct?: Schedule You want to check the status of a database, a webpage after many known operations. -:::tip Alternative +:::tip[Alternative] Most of the time, model based testing might be a better fit for that purpose. ::: @@ -258,7 +258,7 @@ fc.assert( This pattern can be helpful whenever you need to make sure that continuations attached to your tasks get called in proper contexts. For instance, when testing React applications, one cannot perform updates of states outside of `act`. -:::tip Finer act +:::tip[Finer act] The `act` function can be defined on case by case basis instead of being defined globally for all tasks. Check the `act` argument available on the methods of the scheduler. ::: @@ -306,6 +306,6 @@ function buildWrapWithTimersAct(s: fc.Scheduler) { Model-based testing features can be combined with race condition detection through the use of [`scheduledModelRun`](/docs/api/functions/scheduledModelRun). By utilizing this function, the execution of the model will also be processed through the scheduler. -:::warning Do not depend on other scheduled tasks in the model +:::warning[Do not depend on other scheduled tasks in the model] Neither `check` nor `run` should rely on the completion of other scheduled tasks to fulfill themselves. But they can still trigger new scheduled tasks as long as they don't wait for them to resolve. ::: diff --git a/website/docs/configuration/custom-reports.md b/website/docs/configuration/custom-reports.md index b250eebe..886c2836 100644 --- a/website/docs/configuration/custom-reports.md +++ b/website/docs/configuration/custom-reports.md @@ -21,7 +21,7 @@ Got error: AssertionError: expected 1000000000 to be less than or equal to 2 While easily redeable, you may want to format it differently. Explaining how you can do that is the aim of this page. -:::info How to read such reports? +:::info[How to read such reports?] If you want to know more concerning how to read such reports, you may refer to the [Read Test Reports](/docs/tutorials/quick-start/read-test-reports/) section of our [Quick Start](/docs/tutorials/quick-start/basic-setup/) tutorial. ::: @@ -56,7 +56,7 @@ fc.assert( In case your reporter is relying on asynchronous code, you can specify it by setting `asyncReporter` instead of `reporter`. Contrary to `reporter` that will be used for both synchronous and asynchronous properties, `asyncReporter` is forbidden for synchronous properties and makes them throw. -:::info Before `reporter` and `asyncReporter` +:::info[Before `reporter` and `asyncReporter`] In the past, writing your own reporter would have been done as follow: ```js @@ -124,7 +124,7 @@ fc.assert( ) ``` -:::info CodeSandbox documentation +:::info[CodeSandbox documentation] The official documentation explaining how to build CodeSandbox environments from an url is available here: https://codesandbox.io/docs/importing#get-request. ::: @@ -158,7 +158,7 @@ Object.defineProperties(myPromisePossiblyResolved, { }); ``` -:::info Limitations of async variant +:::info[Limitations of async variant] Note that: - `asyncToStringMethod` is only used for asynchronous properties. @@ -166,6 +166,6 @@ Note that: ::: -:::tip Test your custom `toString` +:::tip[Test your custom `toString`] One way to ensure that your instances will be properly stringified is to call the `stringify` function provided by fast-check. This will give you a preview of how your instances will be represented in the output. ::: diff --git a/website/docs/configuration/global-settings.md b/website/docs/configuration/global-settings.md index 8061a0f5..dfd06cfc 100644 --- a/website/docs/configuration/global-settings.md +++ b/website/docs/configuration/global-settings.md @@ -48,7 +48,7 @@ test('test #3', () => { `configureGlobal` fully resets the settings. In other words, it fully drops the previously defined global settings if any even if they applied on other keys. ::: -:::tip Enrich existing global settings +:::tip[Enrich existing global settings] If you want to only add new options on top of the existing ones you may want to use `readConfigureGlobal` as follow: ```js @@ -58,7 +58,7 @@ fc.configureGlobal({ ...fc.readConfigureGlobal(), ...myNewOptions }); You can also fully reset all the global options by calling `resetConfigureGlobal`. ::: -:::info Plugins +:::info[Plugins] [Plugins](/docs/core-blocks/plugins/) cannot be shared via `configureGlobal`, they have their own installer: `fc.installGlobalPlugin(myPlugin())`. ::: diff --git a/website/docs/configuration/timeouts.md b/website/docs/configuration/timeouts.md index 5d804690..033e8c99 100644 --- a/website/docs/configuration/timeouts.md +++ b/website/docs/configuration/timeouts.md @@ -18,7 +18,7 @@ Let's dig into the multiple timeout options provided by fast-check. You can use the `timeout` option with the `assert` function in fast-check to limit the amount of time allocated to run each instance of the predicate defined by your property. If the predicate takes longer than the specified time, the execution will be reported as a failure. fast-check will then attempt to shrink the inputs so that you can more easily identify the cause of the timeout. -:::warning Need asynchronous properties +:::warning[Need asynchronous properties] It's important to note that the `timeout` option only works with asynchronous properties as it needs a way to interrupt another running script. If you want to use it with synchronous code, you can check out the `@fast-check/worker` package. ::: @@ -46,7 +46,7 @@ await fc.assert( In the provided example, the `timeout` will only be triggered if one execution of `async (packages, selectedSeed) => {...}` takes more than 1 second. It's also important to highlight the fact that the timeout option can only intervene for asynchronous tasks taking too long. In other words, in the predicate above, only the code executed asynchronously during the execution of `extractAllDependenciesFor` could be bypassed and raise a timeout issue. -:::info Cannot stop the async code +:::info[Cannot stop the async code] It's important to note that fast-check cannot stop the execution of a running `Promise` as there is no way to cancel it in JavaScript. As a result, if a run takes too long to execute and exceeds the specified timeout limit, fast-check will simply ignore the follow-up results. This means that the code will continue to run until it completes, even if fast-check reported a timeout failure. If you want to stop asynchronous code abruptly when it takes too long, you can check out the `@fast-check/worker` package. It provides a way to run code in a separate worker thread and stop the worker thread if it takes too long, effectively interrupting the execution of the code. @@ -68,7 +68,7 @@ Hint: Enable verbose mode in order to have the list of all failing values encoun at process.processTimers (node:internal/timers:509:9) ``` -:::info Interaction with `beforeEach` and `afterEach` +:::info[Interaction with `beforeEach` and `afterEach`] Note that the function provided to `beforeEach` and `afterEach` are not included in the measured time for the timeout. If the execution is interrupted due to a timeout, `afterEach` will be called immediately without waiting for the predicate to finish. ::: @@ -91,7 +91,7 @@ Here is a summary: | with at least one success | Success | Failure | | during shrink phase | Failure (shrink only happens on failures) | Failure | -:::tip Companion for Fuzzing +:::tip[Companion for Fuzzing] `interruptAfterTimeLimit` is particularly useful for fuzzing. For instance, setting it to `interruptAfterTimeLimit: 600_000` and adding `numRuns: Number.POSITIVE_INFINITY` would allow the runner to loop for 10 minutes, regardless of the number of predicates executed during that time. ::: @@ -121,7 +121,7 @@ Hint (3): Enable verbose mode at level VeryVerbose in order to check all generat During the shrinking process, skipping predicates will result in one-by-one skipping of all the executions required by the shrinker. -:::info Interrupting is more efficient +:::info[Interrupting is more efficient] When we skip a predicate due to the `skipAllAfterTimeLimit` option, we still pass on it, which may take time. This is because each subsequent run needs to be marked as "will not be executed" one by one. On the other hand, with the `interruptAfterTimeLimit` option, the runner is stopped immediately when the deadline is reached, resulting in a faster stop. ::: @@ -136,6 +136,6 @@ Available since 1.15.0. | `interruptAfterTimeLimit` | runner | sync and async | yes | no except when first run or `markInterruptAsFailure:true` | | `skipAllAfterTimeLimit` | runner | sync and async | yes | no except when timeout occured outside of the shrink phase | -:::info Always run `beforeEach` and `afterEach` +:::info[Always run `beforeEach` and `afterEach`] `beforeEach` and `afterEach` functions will always be executed, regardless of whether they are included in the measured time for the timeout or not ::: diff --git a/website/docs/configuration/user-definable-values.md b/website/docs/configuration/user-definable-values.md index 4a6b0d1f..01ce582c 100644 --- a/website/docs/configuration/user-definable-values.md +++ b/website/docs/configuration/user-definable-values.md @@ -36,7 +36,7 @@ fc.assert(fc.property(fc.string(), fc.string(), fc.string(), myCheckFunction), { }); ``` -:::tip Usage with `context` +:::tip[Usage with `context`] If you are using `context` to log within a predicate, you will need to use the following context implementation in your examples. ```ts @@ -49,7 +49,7 @@ fc.assert(fc.property(fc.string(), fc.string(), fc.context(), myCheckFunction), ::: -:::info Trust the framework +:::info[Trust the framework] Please keep in mind that property based testing frameworks are fully able to find corner-cases with no help at all. ::: diff --git a/website/docs/core-blocks/arbitraries/combiners/any.md b/website/docs/core-blocks/arbitraries/combiners/any.md index 13beb1c2..afd89530 100644 --- a/website/docs/core-blocks/arbitraries/combiners/any.md +++ b/website/docs/core-blocks/arbitraries/combiners/any.md @@ -52,7 +52,7 @@ Generate one value based on one of the passed arbitraries Randomly chooses an arbitrary at each new generation. Should be provided with at least one arbitrary. Probability to select a specific arbitrary is based on its weight: `weight(instance) / sumOf(weights)` (for depth=0). For higher depths, the probability to select the first arbitrary will increase as we go deeper in the tree so the formula is not applicable as-is. It preserves the shrinking capabilities of the underlying arbitrary. `fc.oneof` is able to shrink inside the failing arbitrary but not across arbitraries (contrary to `fc.constantFrom` when dealing with constant arbitraries) except if called with `withCrossShrink`. -:::warning First arbitrary, a privileged one +:::warning[First arbitrary, a privileged one] The first arbitrary specified on `oneof` will have a privileged position. Constraints like `withCrossShrink` or `depthSize` tend to favor it over others. ::: @@ -192,7 +192,7 @@ Available since 3.20.0. Drop shrinking capabilities from an existing arbitrary. -:::warning Avoid dropping shrinking capabilities +:::warning[Avoid dropping shrinking capabilities] Although dropping the shrinking capabilities can speed up your CI when failures occur, we do not recommend this approach. Instead, if you want to reduce the shrinking time for automated jobs or local runs, consider using `endOnFailure` or `interruptAfterTimeLimit`. The only potentially legitimate use of dropping shrinking is when creating new complex arbitraries. In such cases, dropping useless parts of the shrinker may prove useful. @@ -220,7 +220,7 @@ Available since 3.20.0. Limit shrinking capabilities of an existing arbitrary. Cap the number of potential shrunk values it could produce. -:::warning Avoid limiting shrinking capabilities +:::warning[Avoid limiting shrinking capabilities] Although limiting the shrinking capabilities can speed up your CI when failures occur, we do not recommend this approach. Instead, if you want to reduce the shrinking time for automated jobs or local runs, consider using `endOnFailure` or `interruptAfterTimeLimit`. The only potentially legitimate use of limiting shrinking is when creating new complex arbitraries. In such cases, limiting some less relevant parts may help preserve shrinking capabilities without requiring exhaustive coverage of the shrinker. @@ -314,7 +314,7 @@ Available since 0.0.1. Flat-Map an existing arbitrary. -:::warning Limited shrink +:::warning[Limited shrink] Be aware that the shrinker of such construct might not be able to shrink as much as possible (more details [here](https://github.com/dubzzz/fast-check/issues/650#issuecomment-648397230)) ::: diff --git a/website/docs/core-blocks/arbitraries/combiners/recursive-structure.md b/website/docs/core-blocks/arbitraries/combiners/recursive-structure.md index c9b0d96d..54b15461 100644 --- a/website/docs/core-blocks/arbitraries/combiners/recursive-structure.md +++ b/website/docs/core-blocks/arbitraries/combiners/recursive-structure.md @@ -204,7 +204,7 @@ Available since 1.16.0. Generate recursive structures. -:::tip Prefer `fc.letrec` when feasible +:::tip[Prefer `fc.letrec` when feasible] Initially `fc.memo` has been designed to offer a higher control over the generated depth. Unfortunately it came with a cost: the arbitrary itself is costly to build. Most of the features offered by `fc.memo` can now be done using `fc.letrec` coupled with `fc.option` or `fc.oneof`. Whenever possible, we recommend using `fc.letrec` instead of `fc.memo`. diff --git a/website/docs/core-blocks/arbitraries/fake-data/file.md b/website/docs/core-blocks/arbitraries/fake-data/file.md index 6a4e31ce..701c4f21 100644 --- a/website/docs/core-blocks/arbitraries/fake-data/file.md +++ b/website/docs/core-blocks/arbitraries/fake-data/file.md @@ -113,7 +113,7 @@ Generate any value eligible to be stringified in JSON and parsed back to itself As `JSON.parse` preserves `-0`, `jsonValue` can also have `-0` as a value. `jsonValue` must be seen as: any value that could have been built by doing a `JSON.parse` on a given string. -:::info Note +:::info[Note] `JSON.parse(JSON.stringify(value))` is not the identity as `-0` is changed into `0` by `JSON.stringify`. ::: diff --git a/website/docs/core-blocks/arbitraries/fake-data/index.md b/website/docs/core-blocks/arbitraries/fake-data/index.md index d3784f0d..189d4932 100644 --- a/website/docs/core-blocks/arbitraries/fake-data/index.md +++ b/website/docs/core-blocks/arbitraries/fake-data/index.md @@ -10,7 +10,7 @@ The fake-data arbitraries produce values that _look_ like production data: UUIDs Reach for them when **your code branches on the shape** of its input — a regex that expects a valid email, a parser that only accepts well-formed URLs, a router that inspects filename extensions. Feeding such code a plain `fc.string()` would spend almost every run in the error path and tell you nothing about the happy path you actually care about. -:::warning Do not over-use fake data +:::warning[Do not over-use fake data] Fake-data arbitraries have narrower shrink spaces than primitives: a shrunk counterexample for `fc.emailAddress()` is still a valid email, not an empty string. When your code does **not** care about the format, plain primitives give better coverage and tighter counterexamples. Use fake data to unblock a specific branch, not as a default. ::: diff --git a/website/docs/core-blocks/arbitraries/others.md b/website/docs/core-blocks/arbitraries/others.md index 202b36e2..b08a0baa 100644 --- a/website/docs/core-blocks/arbitraries/others.md +++ b/website/docs/core-blocks/arbitraries/others.md @@ -111,11 +111,11 @@ Available since . This arbitrary has been designed to simplify the usage of Property Based Testing. It helps to easily leverage Property Based Testing capabilities into tests based on fake-data. -:::warning No replay capabilities +:::warning[No replay capabilities] When replaying failures on properties including a `fc.gen()`, you need to drop the path part. More precisely, you may keep the very first part but have to drop anything after the first ":". ::: -:::warning Must be called in a deterministic order +:::warning[Must be called in a deterministic order] Calls to the produced instance must be done in a determistic order. ::: diff --git a/website/docs/core-blocks/index.md b/website/docs/core-blocks/index.md index f4363aac..ee6d9431 100644 --- a/website/docs/core-blocks/index.md +++ b/website/docs/core-blocks/index.md @@ -15,7 +15,7 @@ Every fast-check test is built from the same four pieces: The children below are the reference pages for each block: start with [Properties](/docs/core-blocks/properties/) if you have never written one, jump to [Arbitraries](/docs/core-blocks/arbitraries/) when you need the right generator and come back to [Plugins](/docs/core-blocks/plugins/) and [Runners](/docs/core-blocks/runners/) when you need to tune execution. -:::tip Reference, not tutorial +:::tip[Reference, not tutorial] The Core Blocks pages are the exhaustive reference. If you are looking for a guided, hands-on walkthrough instead, start with the [Quick Start tutorial](/docs/tutorials/quick-start/basic-setup/). ::: diff --git a/website/docs/core-blocks/properties.md b/website/docs/core-blocks/properties.md index 659ee9b2..79fc8a0f 100644 --- a/website/docs/core-blocks/properties.md +++ b/website/docs/core-blocks/properties.md @@ -17,7 +17,7 @@ They can be summarized by: > such that precondition(x, y, ...) holds > predicate(x, y, ...) is true -:::info Equivalence in fast-check +:::info[Equivalence in fast-check] Each part of the definition can be achieved directly within fast-check: - "_for any (x, y, ...)_" via [arbitraries](/docs/core-blocks/arbitraries/primitives/number/) @@ -45,7 +45,7 @@ The predicate can: - either throw in case of failure by relying on `assert`, `expect` or even directly throwing, - or return `true` or `undefined` for success and `false` for failure. -:::warning Beware of side effects +:::warning[Beware of side effects] The predicate function should not change the inputs it received. If it needs to, it has to clone them before going on. Impacting the inputs might led to bad shrinking and wrong display on error. ::: @@ -61,11 +61,11 @@ fc.property(...arbitraries, (...args) => {}) They both only accept synchronous functions and give the user the ability to call the previously defined hook function if any. The before-each (respectively: after-each) function will be launched before (respectively: after) each execution of the predicate. -:::info Independent +:::info[Independent] No need to define both. You may only call `beforeEach` or `afterEach` without the other. ::: -:::tip Share them +:::tip[Share them] Consider using `fc.configureGlobal` to share your `beforeEach` and `afterEach` functions across multiple properties. ::: @@ -98,7 +98,7 @@ fc.property( ); ``` -:::info Filtering and performance +:::info[Filtering and performance] Whatever the filtering solution you chose between `fc.pre` or `.filter`, they both consist into generating values and then dropping them. When filter is too strict it means that plenty of values could be rejected for only a few kept. As a consequence, whenever feasible it's recommended to prefer relying on options directly providing by the arbitraries rather than filtering them. For instance, if you want to generate strings having at least two characters you should prefer `fc.string({ minLength: 2 })` over `fc.string().filter(s => s.length >= 2)`. @@ -120,6 +120,6 @@ fc.asyncProperty(...arbitraries, async (...args) => {}); They also accept `beforeEach` and `afterEach` functions to be provided: the passed functions can either be synchronous or asynchronous. -:::info Lifecycle +:::info[Lifecycle] The `beforeEach` and `afterEach` functions will always be executed, regardless of whether the property times out. It's important to note that the `timeout` option passed to `fc.assert` only measures the time taken by the actual property test, not the setup and teardown phases. ::: diff --git a/website/docs/core-blocks/runners.md b/website/docs/core-blocks/runners.md index fd722bd9..eb60f7b0 100644 --- a/website/docs/core-blocks/runners.md +++ b/website/docs/core-blocks/runners.md @@ -45,7 +45,7 @@ The structure `RunDetails` provides all the details needed to report what happen | execution took too long given `interruptAfterTimeLimit` | `true` | `true` | `null` | | successful run | `false` | `true`/`false` | `null` | -:::tip Rewrite `assert` with `check` +:::tip[Rewrite `assert` with `check`] ```js function assert(property, params) { diff --git a/website/docs/ecosystem.md b/website/docs/ecosystem.md index 1002d1e9..9b28bda2 100644 --- a/website/docs/ecosystem.md +++ b/website/docs/ecosystem.md @@ -8,7 +8,7 @@ sidebar_label: Ecosystem Bring additional capabilities to fast-check by leveraging its rich ecosystem of extensions and plugins -:::warning Stability +:::warning[Stability] This page provides a list of packages available in the fast-check ecosystem. It includes both official and third-party packages. While we can ensure the stability, usage, and maintenance of the official packages, we cannot provide any specific details or guarantees regarding the non-official packages.
@@ -470,7 +470,7 @@ if (isMainThread) { } ``` -:::info Integration with Jest runner +:::info[Integration with Jest runner] `@fast-check/worker` is directly integrating with `@fast-check/jest`. Checkout the [official documentation of `@fast-check/jest`](https://www.npmjs.com/package/@fast-check/jest) for more details. ::: diff --git a/website/docs/introduction/getting-started.md b/website/docs/introduction/getting-started.md index 69b2282c..f229447e 100644 --- a/website/docs/introduction/getting-started.md +++ b/website/docs/introduction/getting-started.md @@ -15,7 +15,7 @@ fast-check can be installed into any existing project by running the following c npm install --save-dev fast-check ``` -:::tip Experimental versions +:::tip[Experimental versions] All versions of fast-check, including experimental ones, are published to [pkg.pr.new](https://github.com/stackblitz-labs/pkg.pr.new). This means you can try out the latest features without waiting for an official release. @@ -29,7 +29,7 @@ npm install --save-dev https://pkg.pr.new/fast-check@main ::: -:::info Integration with test runners +:::info[Integration with test runners] fast-check is agnostic of the test runner you rely on. It works with any test runner without needing any specific change. ::: @@ -66,7 +66,7 @@ describe('properties', () => { }); ``` -:::tip Hands on Property-Based Testing +:::tip[Hands on Property-Based Testing] If you want to quickly get started with property-based testing, you may check our tutorials and our [quick start guide](/docs/tutorials/quick-start/basic-setup/). ::: diff --git a/website/docs/introduction/index.md b/website/docs/introduction/index.md index babe9de0..eddc15df 100644 --- a/website/docs/introduction/index.md +++ b/website/docs/introduction/index.md @@ -15,7 +15,7 @@ This section is the why of fast-check, not the how. Four pages, each answering a - **Track record.** Real projects and bugs that property-based testing and fast-check specifically have caught. - **Getting started.** Installing fast-check and running your first property in your existing test runner. -:::tip Prefer learning by doing? +:::tip[Prefer learning by doing?] If you would rather skip the theory and open an editor, head straight to the [Quick Start tutorial](/docs/tutorials/quick-start/basic-setup/). It walks you through a runnable project step by step. Come back here whenever you want the background. ::: diff --git a/website/docs/migration/from-3.x-to-4.x.md b/website/docs/migration/from-3.x-to-4.x.md index ccfc3c7b..e3c0d0d2 100644 --- a/website/docs/migration/from-3.x-to-4.x.md +++ b/website/docs/migration/from-3.x-to-4.x.md @@ -276,7 +276,7 @@ function unicode(): Arbitrary {
-:::warning You probably don't need `unicode`/`unicodeString` +:::warning[You probably don't need `unicode`/`unicodeString`] The `unicode` arbitrary was introduced early in fast-check, but later, `fullUnicode` was added to provide full Unicode support. `unicode` stayed limited to characters from the BMP (Basic Multilingual Plane). @@ -409,7 +409,7 @@ Related pull requests: [#5590](https://github.com/dubzzz/fast-check/pull/5590) ### Faster `scheduler` -:::tip Prefer `waitNext`, `waitIdle`, or `waitFor` +:::tip[Prefer `waitNext`, `waitIdle`, or `waitFor`] Since v4.2.0, `waitOne` and `waitAll` are deprecated in favor of `waitNext`, `waitIdle`, and `waitFor`, which behave more predictably — especially when tasks are scheduled after a few awaits, not immediately. diff --git a/website/docs/tutorials/detect-race-conditions/index.md b/website/docs/tutorials/detect-race-conditions/index.md index 689f9715..afb549d2 100644 --- a/website/docs/tutorials/detect-race-conditions/index.md +++ b/website/docs/tutorials/detect-race-conditions/index.md @@ -8,7 +8,7 @@ description: What's the plan for this tutorial? Learn how to detect race conditions in your code through clear and instructive examples -:::tip Already familiar with race conditions? +:::tip[Already familiar with race conditions?] This tutorial teaches techniques to detect race conditions in code testing, using specific algorithms and tools related to fast-check. It includes examples designed to initially pass the tests, and each section introduces new concepts. ➡️ You already know what are race conditions? **Let's start immediately with [the first section](/docs/tutorials/detect-race-conditions/your-first-race-condition-test/)!** 🚀 @@ -28,7 +28,7 @@ import DocCardList from '@theme/DocCardList'; ## Definition of a race condition -:::info Let's align our understanding of the concept +:::info[Let's align our understanding of the concept] While this section is fully optional, it has the benefit to make sure that we all align on the definition of race condition throughout this tutorial. ::: @@ -59,6 +59,6 @@ In other words, the issue occurred as the user performed two searches subsequent As we have seen in this simple example, race conditions are easy to create, as they only require two concurrent events, and can cause significant problems from a user's perspective. It is worth noting that the example we took for this section was only a visual glitch, but race conditions can have much more critical impacts than just a wrong display. -:::tip How to solve them? +:::tip[How to solve them?] This tutorial is designed to guide you in adding tests to your codebase, ensuring the absence race condition issues in the future. It will not directly focus on giving you keys to solve them. For more in-depth information on solving race conditions and useful techniques for identifying them outsite of tests, refer to the article ["Handling API request race conditions in React" by Sébastien Lorber](https://sebastienlorber.com/handling-api-request-race-conditions-in-react). ::: diff --git a/website/docs/tutorials/detect-race-conditions/multiple-batches-of-calls.mdx b/website/docs/tutorials/detect-race-conditions/multiple-batches-of-calls.mdx index 9154e894..f07cb124 100644 --- a/website/docs/tutorials/detect-race-conditions/multiple-batches-of-calls.mdx +++ b/website/docs/tutorials/detect-race-conditions/multiple-batches-of-calls.mdx @@ -67,7 +67,7 @@ const { task } = s.scheduleSequence([ // faulty if you want to know bugs that may have occurred during the sechduling of it. ``` -:::info Non-batched alternative? +:::info[Non-batched alternative?] We will discuss about a non-batched alternative in the next page. The batch option we suggest here has the benefit to make you use the [`scheduleSequence`](/docs/advanced/race-conditions/#schedulesequence) helper coming with fast-check. ::: @@ -75,7 +75,7 @@ We will discuss about a non-batched alternative in the next page. The batch opti -:::info What to expect? +:::info[What to expect?] Your test should help us to detect a bug in our current implementation of `queue`. ::: diff --git a/website/docs/tutorials/detect-race-conditions/one-step-closer-to-real-usages.mdx b/website/docs/tutorials/detect-race-conditions/one-step-closer-to-real-usages.mdx index e1559a7c..421d1d99 100644 --- a/website/docs/tutorials/detect-race-conditions/one-step-closer-to-real-usages.mdx +++ b/website/docs/tutorials/detect-race-conditions/one-step-closer-to-real-usages.mdx @@ -56,7 +56,7 @@ The current implementation of our test only involves running two calls, but ther -:::info What to expect? +:::info[What to expect?] Your test should help us to detect a bug in our current implementation of `queue`. ::: diff --git a/website/docs/tutorials/detect-race-conditions/the-missing-part.mdx b/website/docs/tutorials/detect-race-conditions/the-missing-part.mdx index 7f0866a5..4ee34ae6 100644 --- a/website/docs/tutorials/detect-race-conditions/the-missing-part.mdx +++ b/website/docs/tutorials/detect-race-conditions/the-missing-part.mdx @@ -37,7 +37,7 @@ for (let id = 0; id !== numCalls; ++id) { } ``` -:::info Comparison +:::info[Comparison] Contrary to the batch approach, the ordering of ids will not be ensured. For that reason, we decided to include it in the reports by scheduling a resolved promise with a value featuring this id. ::: @@ -56,7 +56,7 @@ Although we thoroughly tested the first point, we may have overlooked the second -:::info What to expect? +:::info[What to expect?] Your test should help us to detect a bug in our current implementation of `queue`. ::: diff --git a/website/docs/tutorials/detect-race-conditions/wrapping-up.mdx b/website/docs/tutorials/detect-race-conditions/wrapping-up.mdx index 4b55c6c4..12ce0dbe 100644 --- a/website/docs/tutorials/detect-race-conditions/wrapping-up.mdx +++ b/website/docs/tutorials/detect-race-conditions/wrapping-up.mdx @@ -8,7 +8,7 @@ import { WrapUpPlaygroundQueue } from './Playgrounds'; # Wrapping up -:::tip Wanna play? +:::tip[Wanna play?] Want to directly try out the final result? Skip ahead to the [Have fun!](#have-fun) section to play with the code snippets we've created. ::: @@ -145,7 +145,7 @@ To enhance our existing tests with this capability, we can modify our mock `call -:::info The files +:::info[The files] The playground provided includes source files extracted from the previous sections of this tutorial. Inside the `src` directory, you will find various implementations of the `queue` algorithm that you encountered and attempted to defeat throughout the tutorial. For example, `src/queue.v0.js` represents the initial implementation you encountered in part 1, while `src/queue.v1.js` would pass the tests from part 1 but fail those from part 2. diff --git a/website/docs/tutorials/detect-race-conditions/your-first-race-condition-test.mdx b/website/docs/tutorials/detect-race-conditions/your-first-race-condition-test.mdx index 211b3ce9..2e45e213 100644 --- a/website/docs/tutorials/detect-race-conditions/your-first-race-condition-test.mdx +++ b/website/docs/tutorials/detect-race-conditions/your-first-race-condition-test.mdx @@ -70,11 +70,11 @@ In the context of race conditions, we want fast-check to provide us with a sched After pushing scheduled calls into the scheduler, we must execute and release them at some point. This is typically done using `waitAll` or `waitFor`. These APIs simply wait for `waitX` to resolve, indicating that what we were waiting for has been accomplished. -:::info Which wait is the best? +:::info[Which wait is the best?] For this first iteration, both of them will be ok, but we will see later that `waitFor` is probably a better fit in that specific example. ::: -:::tip More +:::tip[More] For a comprehensive list of methods exposed on the scheduler, you can checkout the [official documentation for race conditions](/docs/advanced/race-conditions/). ::: @@ -82,7 +82,7 @@ For a comprehensive list of methods exposed on the scheduler, you can checkout t -:::info What to expect? +:::info[What to expect?] Your test should help us to detect a bug in our current implementation of `queue`. ::: diff --git a/website/docs/tutorials/index.md b/website/docs/tutorials/index.md index cceca851..a594097e 100644 --- a/website/docs/tutorials/index.md +++ b/website/docs/tutorials/index.md @@ -17,7 +17,7 @@ Reading the reference documentation tells you _what_ fast-check can do. Followin - highlights the fast-check features that matter most for that scenario, - ends with takeaways you can immediately bring back to your own codebase. -:::tip New to Property-Based Testing? +:::tip[New to Property-Based Testing?] If the concept itself is new, start by reading [What is Property-Based Testing?](/docs/introduction/what-is-property-based-testing/) and [Why Property-Based?](/docs/introduction/why-property-based/) before diving in. ::: diff --git a/website/docs/tutorials/quick-start/basic-setup.md b/website/docs/tutorials/quick-start/basic-setup.md index f9bbb147..6c4f2fe8 100644 --- a/website/docs/tutorials/quick-start/basic-setup.md +++ b/website/docs/tutorials/quick-start/basic-setup.md @@ -13,7 +13,7 @@ In this tutorial, you'll need to have [Node.js](https://nodejs.org/en/download/) We will start from an already bootstrapped project to focus on our target: writing our first test. -:::info Setup +:::info[Setup] You may want to refer to our [Getting Started](/docs/introduction/getting-started/) section to setup fast-check in an existing project or without tutorial related code. ::: @@ -33,7 +33,7 @@ Our tutorial project is rather small, it contains the following files: This project is relying on [Vitest](https://vitest.dev/) to run the tests. -:::tip Test runners +:::tip[Test runners] Whether you prefer using [Jest](https://jestjs.io/), [Vitest](https://vitest.dev/), [Ava](https://github.com/avajs/ava#readme) or any other, choice is yours! fast-check is designed to be independent of the test runner you use, so you can choose the runner that works best for your project. ::: diff --git a/website/docs/tutorials/quick-start/read-test-reports.md b/website/docs/tutorials/quick-start/read-test-reports.md index e476b656..f09f5c2b 100644 --- a/website/docs/tutorials/quick-start/read-test-reports.md +++ b/website/docs/tutorials/quick-start/read-test-reports.md @@ -17,7 +17,7 @@ npm test Tests should not pass. -:::info What about the unit tests? +:::info[What about the unit tests?] The unit tests we wrote in the previous section are fully green. They were not able to detect any issue. The values that have been hardcoded into them all contains the same number of digits and thus do not fall into all the corner cases. In JavaScript, `sort` orders elements based on their string representation: `[1, 10, 2].sort()` is `[1, 10, 2]`. In the past, `sort` suffered from other strange edges cases: it was stable when receiving less than 10 elements, unstable above 10. For all these reasons, property-based testing is a powerful ally. @@ -48,7 +48,7 @@ We also see that given `data = [2,1000000000]`, the predicate fails with the fol AssertionError: expected 1000000000 to be less than or equal to 2 ``` -:::info What is the predicate? +:::info[What is the predicate?] In the property we wrote, the predicate is: ```js @@ -91,7 +91,7 @@ The parameters `path` or `endOnFailure` can be dropped if needed: - `path` — start the execution directly on the reduced counterexample - `endOnFailure` — immediately stop the execution on failure and do not attempt to shrink the case -:::info Case reduction _aka. shrink_ +:::info[Case reduction _aka. shrink_] By default, property-based testing frameworks try to reduce the counterexamples so that users get reported easier to troubleshoot errors. Instead of telling you: "_failed for `stringValue = "abc{...10k more letters}ert"`_", it will come to you with "_failed for `stringValue = "az"`_". ::: @@ -112,7 +112,7 @@ test('should sort numeric elements from the smallest to the largest one', () => }); ``` -:::info Verbosity values +:::info[Verbosity values] By default, verbose is set to 0. But you can set it to 1 or 2 to get more details. ::: diff --git a/website/docs/tutorials/setting-up-your-test-environment/property-based-testing-manual-setup.md b/website/docs/tutorials/setting-up-your-test-environment/property-based-testing-manual-setup.md index c75daa19..803274e7 100644 --- a/website/docs/tutorials/setting-up-your-test-environment/property-based-testing-manual-setup.md +++ b/website/docs/tutorials/setting-up-your-test-environment/property-based-testing-manual-setup.md @@ -9,7 +9,7 @@ sidebar_label: Manual setup fast-check is designed to be test runner agnostic. You can plug it into any existing test runner without needing a dedicated connector. This page walks through the generic setup that applies whatever runner you use — from runners that do not have a dedicated connector (such as the [Node.js test runner](/docs/tutorials/setting-up-your-test-environment/property-based-testing-with-nodejs-test-runner/), [Bun test runner](/docs/tutorials/setting-up-your-test-environment/property-based-testing-with-bun-test-runner/), [Deno test runner](/docs/tutorials/setting-up-your-test-environment/property-based-testing-with-deno-test-runner/), Mocha, AVA, …) to runners where you prefer full control over connectors like [@fast-check/jest](https://www.npmjs.com/package/@fast-check/jest) or [@fast-check/vitest](https://www.npmjs.com/package/@fast-check/vitest). -:::tip Runner has a connector? +:::tip[Runner has a connector?] If you use [Jest](/docs/tutorials/setting-up-your-test-environment/property-based-testing-with-jest/) or [Vitest](/docs/tutorials/setting-up-your-test-environment/property-based-testing-with-vitest/), we recommend starting with our dedicated connector library — it simplifies integration and handles timeouts and lifecycle for you. The manual setup described here remains a valid alternative whenever you need ultimate flexibility. ::: @@ -50,7 +50,7 @@ You can now run your test with your usual test command. You've just written your first Property-Based Test 🚀 -:::info Where does `fc.property` come from? +:::info[Where does `fc.property` come from?] `fc.property` is the standard way to declare a synchronous property in fast-check. For a deeper dive into properties, arbitraries, and predicates, refer to the [Properties documentation](/docs/core-blocks/properties/). ::: @@ -99,7 +99,7 @@ You can now run your test with your usual test command. You've just written your first asynchronous Property-Based Test 🚀 -:::info Synchronous vs asynchronous predicates +:::info[Synchronous vs asynchronous predicates] When the predicate is asynchronous, you must use `fc.asyncProperty` instead of `fc.property`, and `await` the call to `fc.assert`. More details are available in the [Asynchronous properties section](/docs/core-blocks/properties/#asynchronous-properties). ::: @@ -117,7 +117,7 @@ With this setup, fast-check will interrupt any property-based test that exceeds How you hook this configuration call so it runs before your tests depends on your runner. The [Global settings documentation](/docs/configuration/global-settings/#integration-with-test-frameworks) covers the most common cases (Jest, Mocha, Vitest). Most other runners offer an equivalent mechanism (for example a `--require`/`--import` flag, or a preload option). -:::warning Multiple time limits +:::warning[Multiple time limits] The global setup documented above does not automatically adapt to command-line or test-level time limits. Unlike connector libraries such as `@fast-check/jest` or `@fast-check/vitest`, it will ignore any customized time limit passed via the runner's CLI or at individual test level. ::: diff --git a/website/docs/tutorials/setting-up-your-test-environment/property-based-testing-with-bun-test-runner.md b/website/docs/tutorials/setting-up-your-test-environment/property-based-testing-with-bun-test-runner.md index b975c683..89c6c7ed 100644 --- a/website/docs/tutorials/setting-up-your-test-environment/property-based-testing-with-bun-test-runner.md +++ b/website/docs/tutorials/setting-up-your-test-environment/property-based-testing-with-bun-test-runner.md @@ -19,7 +19,7 @@ bun install -D fast-check Congratulations, everything is ready to start using Property-Based Tests with the Bun test runner 🚀 -:::info Runner-agnostic patterns +:::info[Runner-agnostic patterns] fast-check does not ship a dedicated connector for Bun: you use it the same way you would with any other runner. For the generic sync and async patterns, along with tips on sharing configuration via `fc.configureGlobal`, refer to our [Manual setup](/docs/tutorials/setting-up-your-test-environment/property-based-testing-manual-setup/) page. The rest of this tutorial focuses on the Bun-specific bits. ::: diff --git a/website/docs/tutorials/setting-up-your-test-environment/property-based-testing-with-deno-test-runner.md b/website/docs/tutorials/setting-up-your-test-environment/property-based-testing-with-deno-test-runner.md index 7e5a9424..a23b5bb1 100644 --- a/website/docs/tutorials/setting-up-your-test-environment/property-based-testing-with-deno-test-runner.md +++ b/website/docs/tutorials/setting-up-your-test-environment/property-based-testing-with-deno-test-runner.md @@ -9,7 +9,7 @@ image: /img/socials/fast-check-deno.png Want to start playing with property-based testing in [Deno](https://deno.com/)? Welcome to this short and concise tutorial on integrating fast-check within Deno. -:::info Runner-agnostic patterns +:::info[Runner-agnostic patterns] fast-check does not ship a dedicated connector for Deno: you use it the same way you would with any other runner. For the generic sync and async patterns, along with tips on sharing configuration via `fc.configureGlobal`, refer to our [Manual setup](/docs/tutorials/setting-up-your-test-environment/property-based-testing-manual-setup/) page. The rest of this tutorial focuses on the Deno-specific bits. ::: diff --git a/website/docs/tutorials/setting-up-your-test-environment/property-based-testing-with-jest.md b/website/docs/tutorials/setting-up-your-test-environment/property-based-testing-with-jest.md index 86e87418..8d79e26a 100644 --- a/website/docs/tutorials/setting-up-your-test-environment/property-based-testing-with-jest.md +++ b/website/docs/tutorials/setting-up-your-test-environment/property-based-testing-with-jest.md @@ -17,7 +17,7 @@ We recommend two distinct approaches for integrating fast-check with Jest: Both options have their unique benefits and strengths. This guide walks you through the connector-based approach; the manual path is documented in its own page. -:::info You don't have Jest yet? +:::info[You don't have Jest yet?] If you don't have Jest yet, we recommend you to have a look at their official [Getting Started Guide](https://jestjs.io/docs/getting-started) first. ::: @@ -64,7 +64,7 @@ You can now run your test with your usual test command. You've connected your first Property-Based Test within Jest 🚀 -:::info Changes compared to a usual test +:::info[Changes compared to a usual test] In the above specification file, note that we didn't rely on the `it` or `test` functions from `@jest/globals` or those provided automatically by Jest. Instead, we imported them from `@fast-check/jest`. These imported functions handle everything supported by Jest's `it` and `test`, while also extending them with Property-Based Testing capabilities via `.prop`. ::: @@ -110,7 +110,7 @@ You can now run your test with your usual test command. You've connected your first asynchronous Property-Based Test within Jest 🚀 -:::info Difference with synchronous predicate +:::info[Difference with synchronous predicate] The only difference is that the predicate function is now asynchronous. Compared to the [Manual setup](/docs/tutorials/setting-up-your-test-environment/property-based-testing-manual-setup/) approach, we don't have to use another set of helpers to run asynchronous checks. @@ -135,6 +135,6 @@ The generic sync and async patterns, along with the recommended usage of `fc.con The most common reason to call `fc.configureGlobal` is to align property-based tests with [Jest's default 5-second timeout](https://jestjs.io/docs/cli#--testtimeoutnumber) via `interruptAfterTimeLimit`. Jest exposes `setupFiles` for this use case — the exact snippet (`jest.config.js` + `jest.setup.js`) is documented in the [Jest section of Global settings](/docs/configuration/global-settings/#jest). -:::warning Multiple time limits +:::warning[Multiple time limits] Unlike `@fast-check/jest`, this manual setup does not automatically adapt to command-line or test-level time limits. It will ignore any customized time limit passed via `--testTimeout=` or at test level via `test(label, fn, timeout)`. ::: diff --git a/website/docs/tutorials/setting-up-your-test-environment/property-based-testing-with-nodejs-test-runner.md b/website/docs/tutorials/setting-up-your-test-environment/property-based-testing-with-nodejs-test-runner.md index ab459822..0ed27466 100644 --- a/website/docs/tutorials/setting-up-your-test-environment/property-based-testing-with-nodejs-test-runner.md +++ b/website/docs/tutorials/setting-up-your-test-environment/property-based-testing-with-nodejs-test-runner.md @@ -21,7 +21,7 @@ npm install --save-dev fast-check Congratulations, everything is ready to start using Property-Based Tests with the Node.js test runner 🚀 -:::info Runner-agnostic patterns +:::info[Runner-agnostic patterns] fast-check does not ship a dedicated connector for the Node.js test runner: you use it the same way you would with any other runner. For the generic sync and async patterns, along with tips on sharing configuration via `fc.configureGlobal`, refer to our [Manual setup](/docs/tutorials/setting-up-your-test-environment/property-based-testing-manual-setup/) page. The rest of this tutorial focuses on the Node-specific bits. ::: diff --git a/website/docs/tutorials/setting-up-your-test-environment/property-based-testing-with-vitest.md b/website/docs/tutorials/setting-up-your-test-environment/property-based-testing-with-vitest.md index fa3bc23f..ffe8fb45 100644 --- a/website/docs/tutorials/setting-up-your-test-environment/property-based-testing-with-vitest.md +++ b/website/docs/tutorials/setting-up-your-test-environment/property-based-testing-with-vitest.md @@ -13,12 +13,12 @@ While fast-check is a standalone library that works with any test runner out of Best of all, the connector simply provides an enriched version of Vitest's `test` and `it` functions. This means you can incrementally plug it into an existing test suite without any need to rewrite anything. You can just swap the import from vitest with the one from @fast-check/vitest and later start playing with adding `.prop` where it matters. -:::note What the connector handles for you +:::note[What the connector handles for you] Behind the scenes, the connector takes care of wiring up the timeout, `beforeEach`/`afterEach` hook integration and other Vitest-specific concerns so that property-based tests behave as expected out of the box. ::: -:::info You don't have Vitest yet? +:::info[You don't have Vitest yet?] If you don't have Vitest yet, we recommend you to have a look at their official [Getting Started Guide](https://vitest.dev/guide/) first. ::: @@ -64,7 +64,7 @@ You can now run your test with your usual test command. You've connected your first Property-Based Test within Vitest 🚀 -:::info Changes compared to a usual test +:::info[Changes compared to a usual test] In the above specification file, note that we didn't rely on the `it` or `test` functions from `vitest`. Instead, we imported them from `@fast-check/vitest`. These imported functions handle everything supported by Vitest's `it` and `test`, while also extending them with Property-Based Testing capabilities via `.prop`. Synchronous and asynchronous predicates are both supported without any extra helpers — just mark your predicate `async` when needed. ::: @@ -104,7 +104,7 @@ The `g` function accepts an arbitrary builder (note: passed without calling it) fc.configureGlobal({ seed: }); ``` -:::tip Integrating with Faker +:::tip[Integrating with Faker] You can combine `g` with libraries like [Faker](https://fakerjs.dev/) to produce realistic test data while maintaining full control over randomness: