API Reference | fast-check | Property based testing framework
    Preparing search index...

    Interface Scheduler<TMetaData>

    Instance able to reschedule the ordering of promises for a given app

    Since 1.20.0

    interface Scheduler<TMetaData = unknown> {
        report: () => SchedulerReportItem<TMetaData>[];
        schedule: <T>(
            task: Promise<T>,
            label?: string,
            metadata?: TMetaData,
            customAct?: SchedulerAct,
        ) => Promise<T>;
        scheduleFunction: <TArgs extends any[], T>(
            asyncFunction: (...args: TArgs) => Promise<T>,
            customAct?: SchedulerAct,
        ) => (...args: TArgs) => Promise<T>;
        waitAll: (customAct?: SchedulerAct) => Promise<void>;
        waitFor: <T>(
            unscheduledTask: Promise<T>,
            customAct?: SchedulerAct,
        ) => Promise<T>;
        waitIdle: (customAct?: SchedulerAct) => Promise<void>;
        waitNext: (count: number, customAct?: SchedulerAct) => Promise<void>;
        waitOne: (customAct?: SchedulerAct) => Promise<void>;
        count(): number;
        scheduleSequence(
            sequenceBuilders: SchedulerSequenceItem<TMetaData>[],
            customAct?: SchedulerAct,
        ): {
            done: boolean;
            faulty: boolean;
            task: Promise<{ done: boolean; faulty: boolean }>;
        };
    }

    Type Parameters

    • TMetaData = unknown
    Index

    Properties

    report schedule scheduleFunction waitAll waitFor waitIdle waitNext waitOne

    Methods

    count scheduleSequence

    Properties

    report: () => SchedulerReportItem<TMetaData>[]

    Produce an array containing all the scheduled tasks so far with their execution status. If the task has been executed, it includes a string representation of the associated output or error produced by the task if any.

    Tasks will be returned in the order they get executed by the scheduler.

    Since 1.25.0

    schedule: <T>(
        task: Promise<T>,
        label?: string,
        metadata?: TMetaData,
        customAct?: SchedulerAct,
    ) => Promise<T>

    Wrap a new task using the Scheduler

    Since 1.20.0

    scheduleFunction: <TArgs extends any[], T>(
        asyncFunction: (...args: TArgs) => Promise<T>,
        customAct?: SchedulerAct,
    ) => (...args: TArgs) => Promise<T>

    Automatically wrap function output using the Scheduler

    Since 1.20.0

    waitAll: (customAct?: SchedulerAct) => Promise<void>

    Wait all scheduled tasks, including the ones that might be created by one of the resolved task

    Since 1.20.0

    Use waitIdle() instead, it comes with a more predictable behavior awaiting all scheduled and reachable tasks to be completed

    waitFor: <T>(
        unscheduledTask: Promise<T>,
        customAct?: SchedulerAct,
    ) => Promise<T>

    Wait as many scheduled tasks as need to resolve the received Promise

    Some tests frameworks like supertest are not triggering calls to subsequent queries in a synchronous way, some are waiting an explicit call to then to trigger them (either synchronously or asynchronously)... As a consequence, none of waitOne or waitAll cannot wait for them out-of-the-box.

    This helper is responsible to wait as many scheduled tasks as needed (but the bare minimal) to get unscheduledTask resolved. Once resolved it returns its output either success or failure.

    Be aware that while this helper will wait eveything to be ready for unscheduledTask to resolve, having uncontrolled tasks triggering stuff required for unscheduledTask might be a source a uncontrollable and not reproducible randomness as those triggers cannot be handled and scheduled by fast-check.

    Since 2.24.0

    waitIdle: (customAct?: SchedulerAct) => Promise<void>

    Wait until the scheduler becomes idle: all scheduled and reachable tasks have completed.

    It will include tasks scheduled by other tasks, recursively.

    Note: Tasks triggered by uncontrolled sources (like fetch or external events) cannot be detected or awaited and may lead to incomplete waits.

    If you want to wait for a precise event to happen you should rather opt for waitFor or waitNext given they offer you a more granular control on what you are exactly waiting for.

    Since 4.2.0

    waitNext: (count: number, customAct?: SchedulerAct) => Promise<void>

    Wait and schedule exactly count scheduled tasks.

    Since 4.2.0

    waitOne: (customAct?: SchedulerAct) => Promise<void>

    Wait one scheduled task to be executed

    Whenever there is no task scheduled

    Since 1.20.0

    Use waitNext(1) instead, it comes with a more predictable behavior

    Methods

    • Schedule a sequence of Promise to be executed sequencially. Items within the sequence might be interleaved by other scheduled operations.

      Please note that whenever an item from the sequence has started, the scheduler will wait until its end before moving to another scheduled task.

      A handle is returned by the function in order to monitor the state of the sequence. Sequence will be marked:

      • done if all the promises have been executed properly
      • faulty if one of the promises within the sequence throws

      Parameters

      Returns {
          done: boolean;
          faulty: boolean;
          task: Promise<{ done: boolean; faulty: boolean }>;
      }

      Since 1.20.0

    Settings

    Member Visibility

    On This Page

    Properties
    Methods