@j-schreiber/sf-cli-plugin-api-testing

A small utility to create, maintain, and run data-driven API tests. Scaffolds directories, creates test cases, provides frameworks for test data setup/teardown and assertions, and finally runs tests.

Installation

To build from source, follow these steps

git clone https://github.com/j-schreiber/js-sf-cli-api-testing
cd js-sf-cli-api-testing
yarn && yarn build
sf plugins link .

To install the latest version from NPM

sf plugins install @j-schreiber/sf-cli-plugin-api-testing

To use in CI (example with two plugins)

steps:
  - name: Install CLI Bundle
    uses: allvest/salesforce-gha-tools/.github/actions/install@main
    with:
      plugins: |
        @j-schreiber/sf-plugin
        @j-schreiber/sf-cli-plugin-api-testing

Local Development & NUTs (Scratch Org Integration Tests)

CI currently does not run NUTs - they are commited, but only run locally. NUTs depend on dotenv. Use .env.example to set up your .env. .mocharc.json requires dotenv/config, which exports the AUTH_URL and INSTALLATION_KEY for the test run execution.

yarn test:nuts

Test Case Authoring

Test cases live on disk under a --source-dir in a fixed two-level layout: a single/ or list/ event-kind directory, then an event-path subdirectory (e.g. my-event.v1) whose name is used verbatim as the final URL segment, then one .json file per test case. The discover command validates this layout offline; the run command executes the valid cases and asserts their responses.

my-e2e-tests/
├── single/
│   └── account-created.v1/
│       ├── happy-path.json
│       └── missing-fields.json
└── list/
    └── accounts-imported.v1/
        └── batch-of-two.json

Each file can have two forms. The fallback form is a bare payload — the whole document is the request body, and the response is asserted only loosely (see below). The extended form is an object with a request and a response, letting you assert on the response explicitly. Which form applies, and what the response may contain, differs between single and list events.

Single events

A single event POSTs its request to the event resource and expects one response.

• Fallback form: the entire JSON document is the request body. The response defaults to statusCode: 200 with no body assertion.
• Extended form: request is any JSON value (the body to send). response.statusCode defaults to 200; response.body, when present, is matched deep-partially against the actual body — every key/element you specify must be present and equal, but extra keys in the actual response are ignored.

// single/account-created.v1/happy-path.json  (extended form)
{
  "request": { "accountId": "001000000000000AAA", "amount": 42 },
  "response": {
    "statusCode": 201,
    "body": { "result": { "id": "a01000000000000AAA" } }
  }
}

// single/account-created.v1/bare.json  (fallback form — request body only, expects 200)
{ "accountId": "001000000000000AAA" }

List events

A list event POSTs an array of events to the events resource. On success the endpoint replies 207 Multi-Status with a response array carrying one entry per request event. Each entry is a flat object — its statusCode sits alongside the result fields (result, errors, warnings, …) at the same level; there is no nested body. A list case has two response modes, keyed by the expected response.statusCode (which defaults to 207):

• Multi-status (207, the usual case) — the batch was accepted and each event has its own result. response.body, when present, must be an array with one entry per request event (its length must equal the request length), each entry an explicit flat object carrying at least a statusCode. The whole entry is deep-partial matched, so any result fields you list are asserted and extra fields in the actual response are ignored. When response.body is omitted, the runner fills the blanks: it expects a statusCode of 200 for every entry, as many entries as request events. At runtime the assertion additionally checks that the returned array has the same length as the request — equal lengths mean every event was processed and none was dropped.
• Status (non-207, e.g. 400) — the endpoint rejected the request outright (a payload it cannot even deserialize into a list). Set response.statusCode to the expected code; there is no per-entry array, so response.body (when present) is matched flexibly (deep-partial), just like a single response.

Request rules:

• The request must be a JSON array — in the fallback form the top-level document is the array; in the extended form request is the array. A non-array list request is a validation error at discovery.
• validateRequestOnDiscovery (default true) turns that check off when set to false, so you can keep a deliberately malformed request (a non-deserializable plain string, a wrong-typed payload) to test that the endpoint rejects it. Pair it with a non-207 status-mode response.

// list/accounts-imported.v1/batch-of-two.json  (multi-status mode — flat entries)
{
  "request": [{ "accountId": "001...AAA" }, { "accountId": "001...BBB" }],
  "response": {
    "body": [
      { "statusCode": 200, "result": { "id": "a01...AAA" } },
      { "statusCode": 422, "errors": ["duplicate"] }
    ]
  }
}

// list/accounts-imported.v1/all-succeed.json  (fallback form — expects 207 + 200 per entry)
[{ "accountId": "001...AAA" }, { "accountId": "001...BBB" }]

// list/accounts-imported.v1/rejected.json  (status mode — a request the endpoint can't parse)
{
  "request": "}}} not a list {{{",
  "validateRequestOnDiscovery": false,
  "response": {
    "statusCode": 400,
    "body": { "message": "Could not deserialize request into a list" }
  }
}

Hooks

Hooks let a test suite prepare org state before a callout and clean up after it, without leaving that work to be done by hand. A hook is an ordered list of steps (currently only apex, referencing a .apex file); execution and failure semantics are shared across every hook, regardless of where it's declared.

Reserved file names (scope-level hooks)

A directory anywhere in the layout — the source-dir root, a single/list directory, or an event-path directory — can carry hooks by adding one or more of these four reserved file names, each an ordered JSON array of steps:

• before.hook.json — runs once when the directory is entered.
• after.hook.json — runs once when the directory is left.
• beforeEach.hook.json — runs before every test case inside the directory.
• afterEach.hook.json — runs after every test case inside the directory.

// single/account-created.v1/beforeEach.hook.json
[{ "kind": "apex", "file": "single/account-created.v1/reset-account.apex" }]

The .hook.json suffix is what marks a file as a hook manifest rather than a test case — a plain before.json would be read as a test case, not a hook. Each file reference is a path relative to --source-dir, never to the manifest's own directory — so the same reference means the same file whether it's written in the root's before.hook.json or three directories down.

Test-case-level hooks (inline)

A single test case can carry its own before/after steps directly in its JSON, next to request and response, using a hooks property:

// single/account-created.v1/needs-existing-account.json
{
  "request": { "accountId": "001000000000000AAA" },
  "response": { "statusCode": 200 },
  "hooks": {
    "before": [{ "kind": "apex", "file": "scripts/seed-account.apex" }],
    "after": [{ "kind": "apex", "file": "scripts/cleanup-account.apex" }]
  }
}

Only before and after are valid here — there is no beforeEach/afterEach. file resolves relative to --source-dir here too, exactly as it does for a scope-level manifest — nesting the hook inline on the test case does not change the resolution rule.

Nesting

Hooks nest along the same directory chain discover/run already walk: source-dir root → single/list → event-path directory → (optionally) an individual test case. Every level is independent — a directory can have hooks with or without its parent or children having any.

Execution order

For a test case with hooks declared at every level, execution is strictly nested — outermost setup first, innermost teardown last:

1. Root before (once, on first entering the suite)
2. Event-type (single/list) before (once, on first entering that directory)
3. Event-path before (once, on first entering that directory)
4. Root, then event-type, then event-path beforeEach (before this test case, outermost → innermost)
5. The test case's own inline before
6. The test case's callout and assertion
7. The test case's own inline after
8. Event-path, then event-type, then root afterEach (after this test case, innermost → outermost)
9. Event-path after (once, after the last case in that directory)
10. Event-type after (once, after the last case in that directory)
11. Root after (once, after the last case in the suite)

A failed setup step (before/beforeEach) skips the callout it was guarding — but its matching teardown (after/afterEach) still runs, so a partial setup is always cleaned up. --no-hooks bypasses every hook at every level for the run.

Documentation

• sf allvest event debug
• sf allvest event describe
• sf allvest event loop
• sf allvest tests add
• sf allvest tests debug
• sf allvest tests discover
• sf allvest tests run

sf allvest event debug

Send an ad-hoc payload to an event endpoint and stream the request and response.

USAGE
  $ sf allvest event debug -n <value> -o <value> [--json] [--flags-dir <value>] [-b <value> | -f <value>] [-t
    single|list] [--log] [--html-report] [--api-version <value>] [--verbose]

FLAGS
  -b, --body=<value>         The raw request body, inline. Mutually exclusive with --file.
  -f, --file=<value>         Path to a file whose contents are the raw request body. Mutually exclusive with --body.
  -n, --event-name=<value>   (required) The event name (the final URL segment, e.g. "my-event.v1").
  -o, --target-org=<value>   (required) Username or alias of the target org. Not required if the `target-org`
                             configuration variable is already set.
  -t, --type=<option>        [default: single] Event type, selecting the endpoint kind and the required body shape.
                             Defaults to "single".
                             <options: single|list>
      --api-version=<value>  Override the api version used for api requests made by this command
      --html-report          Write a self-contained, shareable HTML report of the callout to the current directory and
                             open it in the default browser. With --log, the captured Apex log is embedded in the report
                             instead of being written to .allvest/logs.
      --log                  Capture the org-side Apex debug log for this callout and save it for the Apex Replay
                             Debugger.
      --verbose              Also print the request body. Hidden by default.

GLOBAL FLAGS
  --flags-dir=<value>  Import flag values from a directory.
  --json               Format output as json.

DESCRIPTION
  Send an ad-hoc payload to an event endpoint and stream the request and response.

  Fires a one-off callout at an event endpoint: it takes a raw request body — inline (--body), from a file (--file), or
  piped in on stdin — and an event name, POSTs it to the constructed endpoint against a target org, and streams
  response.

EXAMPLES
  Send an inline body to a single-event endpoint against your default org

    $ sf allvest event debug --event-name my-event.v1 --body '{"accountId": "001000000000000AAA"}' --target-org \
      my-scratch

  Send the contents of a file as the body

    $ sf allvest event debug --event-name my-event.v1 --file ./payload.json --target-org my-scratch

  Pipe a body in on stdin to a list-event endpoint
  cat payload.json | sf allvest event debug --event-name my-event.v1 --type list --target-org my-scratch

FLAG DESCRIPTIONS
  -b, --body=<value>  The raw request body, inline. Mutually exclusive with --file.

    Enclose the body in single quotes so the shell passes it verbatim. A string-escaped body — the whole payload is
    itself a quoted JSON string, the shape of an event captured off a bus — is un-escaped automatically before sending.
    Its enclosing double-quotes are part of the value, so keep them inside the single quotes, e.g. -b
    '"{\"environment\": ...}"'. (A body without those outer quotes is already a plain object and is sent as-is.)

  -t, --type=single|list  Event type, selecting the endpoint kind and the required body shape. Defaults to "single".

    The root resource that determines whether the "single event" or the "list event" endpoint is used ("single" maps to
    the "event" resource, "list" to "events"). It also selects the required body shape: a "single" body must be a JSON
    object, a "list" body must be a JSON array.

  --log  Capture the org-side Apex debug log for this callout and save it for the Apex Replay Debugger.

    Before sending, ensures an active DEVELOPER_LOG trace flag on the running user (reusing the org's SFDC_DevConsole
    debug level, created-or-extended with a ~30-minute expiry — never deleted), then correlates the callout's response
    to the Apex log it produced and writes that log to .allvest/logs. The log content is never printed; only its saved
    location and size are shown. If no trace flag can be established the command aborts before sending; a log that never
    appears is a warning, not a failure.

See code: src/commands/allvest/event/debug.ts

sf allvest event describe

Describe an event registered on a target org, discovering the available events interactively.

USAGE
  $ sf allvest event describe -o <value> [--json] [--flags-dir <value>] [-n <value>] [--api-version <value>]

FLAGS
  -n, --event-name=<value>   The event to describe (its URI suffix, e.g. "my-event.v1"). When omitted, the org's events
                             are listed and you pick one from a prompt.
  -o, --target-org=<value>   (required) Username or alias of the target org. Not required if the `target-org`
                             configuration variable is already set.
      --api-version=<value>  Override the api version used for api requests made by this command

GLOBAL FLAGS
  --flags-dir=<value>  Import flag values from a directory.
  --json               Format output as json.

DESCRIPTION
  Describe an event registered on a target org, discovering the available events interactively.

  Lists every event registered on the target org (the "/v1/events" discovery endpoint), lets you pick one from an
  interactive prompt, then calls that event's describe endpoint and prints the returned document verbatim.

  Pass --event-name to skip the discovery prompt and describe a specific event directly; this is required with --json,
  where no prompt can be shown.

EXAMPLES
  Discover the org's events and pick one to describe against your default org

    $ sf allvest event describe --target-org my-scratch

  Describe a specific event by name, skipping the prompt

    $ sf allvest event describe --event-name my-event.v1 --target-org my-scratch

  Get the describe document as JSON (a name is required, as no prompt can run)

    $ sf allvest event describe --event-name my-event.v1 --target-org my-scratch --json

See code: src/commands/allvest/event/describe.ts

sf allvest event loop

Re-send an ad-hoc payload to an event endpoint repeatedly until interrupted.

USAGE
  $ sf allvest event loop -n <value> -o <value> [--json] [--flags-dir <value>] [-b <value> | -f <value>] [-t
    single|list] [--api-version <value>] [--verbose]

FLAGS
  -b, --body=<value>         The raw request body, inline. Mutually exclusive with --file.
  -f, --file=<value>         Path to a file whose contents are the raw request body. Mutually exclusive with --body.
  -n, --event-name=<value>   (required) The event name (the final URL segment, e.g. "my-event.v1").
  -o, --target-org=<value>   (required) Username or alias of the target org. Not required if the `target-org`
                             configuration variable is already set.
  -t, --type=<option>        [default: single] Event type, selecting the endpoint kind and the required body shape.
                             Defaults to "single".
                             <options: single|list>
      --api-version=<value>  Override the api version used for api requests made by this command
      --verbose              Also print the request body. Hidden by default.

GLOBAL FLAGS
  --flags-dir=<value>  Import flag values from a directory.
  --json               Format output as json.

DESCRIPTION
  Re-send an ad-hoc payload to an event endpoint repeatedly until interrupted.

  Replays a one-off callout at an event endpoint: it takes a raw request body — inline (--body), from a file (--file),
  or piped in on stdin — and an event name, then re-sends the identical POST to the constructed endpoint against a
  target org, streaming each iteration, until interrupted (Ctrl-C). The body and coordinates are fixed for the whole
  session. Unlike "event debug", it has no --log or --html-report capability.

EXAMPLES
  Poll a single-event endpoint with an inline body until interrupted

    $ sf allvest event loop --event-name my-event.v1 --body '{"ping": true}' --target-org my-scratch

  Replay the contents of a file against a list-event endpoint

    $ sf allvest event loop --event-name my-event.v1 --file ./payload.json --type list --target-org my-scratch

  Pipe a body in on stdin and replay it
  cat payload.json | sf allvest event loop --event-name my-event.v1 --target-org my-scratch

FLAG DESCRIPTIONS
  -b, --body=<value>  The raw request body, inline. Mutually exclusive with --file.

    Enclose the body in single quotes so the shell passes it verbatim. A string-escaped body — the whole payload is
    itself a quoted JSON string, the shape of an event captured off a bus — is un-escaped automatically before sending.
    Its enclosing double-quotes are part of the value, so keep them inside the single quotes, e.g. -b
    '"{\"environment\": ...}"'. (A body without those outer quotes is already a plain object and is sent as-is.)

  -t, --type=single|list  Event type, selecting the endpoint kind and the required body shape. Defaults to "single".

    The root resource that determines whether the "single event" or the "list event" endpoint is used ("single" maps to
    the "event" resource, "list" to "events"). It also selects the required body shape: a "single" body must be a JSON
    object, a "list" body must be a JSON array.

See code: src/commands/allvest/event/loop.ts

sf allvest tests add

Normalize a captured event payload into a test-case body.

USAGE
  $ sf allvest tests add [--json] [--flags-dir <value>] [-j <value>] [-f <value>] [--flatten] [--extract <value>] [-s]
    [-d <value>] [-e <value>] [-n <value>] [--is-extended]

FLAGS
  -d, --tests-dir=<value>   Root directory where tests are stored (parent of the single/list directories).
  -e, --event=<value>       Event name — the directory the test case is written under (e.g. "my-event.v1").
  -f, --file-input=<value>  Path to a file whose contents are the raw event payload.
  -j, --json-input=<value>  Raw event payload as an inline JSON string.
  -n, --name=<value>        Name of the test case, used as the file name (without the .json extension).
  -s, --save                Save the normalized payload as a test case instead of printing it.
      --extract=<value>     Dot-delimited JSON path to extract and use as the output (e.g. "event.body").
      --flatten             Collapse single-key "value" wrappers (Avro schema shape) into their content.
      --[no-]is-extended    Create an extended test case (empty hooks, default 200 response) rather than writing the
                            payload verbatim as a basic case.

GLOBAL FLAGS
  --flags-dir=<value>  Import flag values from a directory.
  --json               Format output as json.

DESCRIPTION
  Normalize a captured event payload into a test-case body.

  Takes a raw event payload — supplied inline with --json-input or read from a file with --file-input — and normalizes
  it into the JSON body a test case carries. Any string-escaped JSON found in the payload is always unescaped and
  parsed, wherever it appears in the tree; this is a common artifact of events captured off a bus.

  By default the normalized payload is printed to the console. Pass --save to write it as a test case into the
  "<tests-dir>/<single|list>/<event>/<name>.json" layout the discover and run commands expect. The event type (single or
  list) is derived from the payload shape — an array is a list event — and the decision is logged. The remaining
  coordinates (--tests-dir, --event, --name) and whether to create an extended case (--is-extended) are taken from their
  flags or prompted for interactively when omitted.

EXAMPLES
  Normalize an inline payload and print it

    $ sf allvest tests add --json-input '{"accountId":"001000000000000AAA"}'

  Read a captured event from a file, flatten its Avro "value" wrappers, and save it as a basic test case

    $ sf allvest tests add --file-input ./captured-event.json --flatten --save --tests-dir my-tests --event \
      my-event.v1 --name happy-path --no-is-extended

  Save an extended test case (seeded with empty hooks and a default 200 response), prompting for any missing
  coordinate

    $ sf allvest tests add --file-input ./captured-event.json --save --is-extended

  Extract a nested body out of a captured envelope

    $ sf allvest tests add --file-input ./captured-event.json --extract event.body

See code: src/commands/allvest/tests/add.ts

sf allvest tests debug

Run a single event test case and stream its request and response to the console.

USAGE
  $ sf allvest tests debug -f <value> -o <value> [--json] [--flags-dir <value>] [--api-version <value>] [-t single|list]
    [-n <value>] [--hooks] [--log] [--html-report] [--verbose]

FLAGS
  -f, --file=<value>         (required) Path to a single event test-case file to run.
  -n, --name=<value>         Event name (e.g. "my-event.v1"), used when it cannot be derived from the file path.
  -o, --target-org=<value>   (required) Username or alias of the target org. Not required if the `target-org`
                             configuration variable is already set.
  -t, --type=<option>        [default: single] Event type, used when it cannot be derived from the file path. Defaults
                             to "single".
                             <options: single|list>
      --api-version=<value>  Override the api version used for api requests made by this command
      --[no-]hooks           Run all enclosing hooks (directory-scope and inline) before the callout (default); use
                             --no-hooks to run only the callout, with no setup or teardown.
      --html-report          Write a self-contained, shareable HTML report of the test case to the current directory and
                             open it in the default browser. With --log, the captured Apex log is embedded in the report
                             instead of being written to .allvest/logs.
      --log                  Capture the org-side Apex debug log for every loggable transaction (each Apex hook step and
                             the callout) and save it for the Apex Replay Debugger.
      --verbose              Also print the request body. Hidden by default.

GLOBAL FLAGS
  --flags-dir=<value>  Import flag values from a directory.
  --json               Format output as json.

DESCRIPTION
  Run a single event test case and stream its request and response to the console.

  Loads one event test case by file path (the same way the "discover" command reads a case, but for a single file) and
  executes it against a target org. By default it also runs the case's enclosing hooks — the directory-scope
  before/after/beforeEach/afterEach and the case's own inline before/after — so the callout runs against the same
  prepared org a real "run" would; use --no-hooks to run only the callout. Streams each hook (the Apex it runs, then its
  pass/fail), followed by the request parameters (method, URL, body) and the response parameters (status code, body), so
  you can inspect a single callout end to end. It then evaluates the test case's assertions exactly as "run" would.

  The event is derived from the file's location on disk, so the file normally lives under a "single" or "list" directory
  (single-event vs list-event payloads) with an event-path subdirectory. When a component cannot be derived from the
  path, supply it with a flag: --type provides the event type (single/list) and --name provides the event name; such a
  non-conventional file has no directory-scope hook chain, so only its inline hooks run.

EXAMPLES
  Debug a single test case against your default org

    $ sf allvest tests debug --file test/data/discover-fixtures/non-empty-dirs/single/my-event.v1/bare-body.json \
      --target-org my-scratch

  Debug a case whose file is not under the conventional directory layout, supplying the event type and name

    $ sf allvest tests debug --file ./my-payload.json --type single --name my-event.v1 --target-org my-scratch

  Capture the org-side Apex debug log for the callout and save it for the Apex Replay Debugger

    $ sf allvest tests debug --file test/data/discover-fixtures/non-empty-dirs/single/my-event.v1/bare-body.json \
      --log --target-org my-scratch

  Write a shareable HTML report of the single test case and open it in the browser

    $ sf allvest tests debug --file test/data/discover-fixtures/non-empty-dirs/single/my-event.v1/bare-body.json \
      --html-report --target-org my-scratch

FLAG DESCRIPTIONS
  -t, --type=single|list  Event type, used when it cannot be derived from the file path. Defaults to "single".

    The root resource that determines whether the "single event" or the "list event" endpoint is used. Only consulted
    when the file does not live under a "single" or "list" directory, so the type cannot be read from its location on
    disk; when it is consulted it defaults to "single".

  --log

    Capture the org-side Apex debug log for every loggable transaction (each Apex hook step and the callout) and save it
    for the Apex Replay Debugger.

    Establishes an active DEVELOPER_LOG trace flag on the running user before the first hook runs (reusing the org's
    SFDC_DevConsole debug level, created-or-extended with a ~30-minute expiry — never deleted), so every hook and the
    callout log at full detail. Each Apex hook step's log is returned inline from its execution; the callout's log is
    correlated from its response to the Apex log it produced and written to .allvest/logs. Each hook's log is streamed
    (truncated to the first lines unless --verbose); the callout log content is never printed, only its saved location
    and size. If no trace flag can be established the command aborts before running anything; a log that never appears
    is a warning, not a failure.

See code: src/commands/allvest/tests/debug.ts

sf allvest tests discover

Discover and validate event test cases in a directory.

USAGE
  $ sf allvest tests discover -d <value> [--json] [--flags-dir <value>]

FLAGS
  -d, --source-dir=<value>  (required) Directory to scan for event test cases.

GLOBAL FLAGS
  --flags-dir=<value>  Import flag values from a directory.
  --json               Format output as json.

DESCRIPTION
  Discover and validate event test cases in a directory.

  Scans a directory for event test cases and validates each one against the expected schema. Looks for the fixed
  "single" and "list" subdirectories (single-event vs list-event payloads), treats each of their subdirectories as an
  event path, and reads every JSON file within as a test case.

  Test cases are printed as a tree, with a checkmark for valid files and an error detail for invalid ones. This command
  does not contact an org; it is intended to check and sanitise test cases before they run in CI. It always exits 0,
  even when invalid test cases are found.

EXAMPLES
  Discover all test cases in a directory

    $ sf allvest tests discover --source-dir my-e2e-tests/data

See code: src/commands/allvest/tests/discover.ts

sf allvest tests run

Run event test cases in a directory against a target org.

USAGE
  $ sf allvest tests run -d <value> -o <value> [--json] [--flags-dir <value>] [--api-version <value>] [--strict] [-f
    <value>] [--succeed-on-empty] [--hooks] [--no-prompt] [--html-report]

FLAGS
  -d, --source-dir=<value>   (required) Directory to scan for event test cases.
  -f, --filter=<value>       Only run test cases whose event path or test-case name contains this term
                             (case-insensitive).
  -o, --target-org=<value>   (required) Username or alias of the target org. Not required if the `target-org`
                             configuration variable is already set.
      --api-version=<value>  Override the api version used for api requests made by this command
      --[no-]hooks           Run the enclosing before/after/beforeEach/afterEach hooks (default); use --no-hooks to run
                             the test cases without executing (or validating) any hooks.
      --html-report          Write a self-contained, shareable HTML report of the run to the current directory and open
                             it in the default browser.
      --no-prompt            Surpresses the prompt for unsafe hooks when run against sandboxes or production. Use with
                             extreme care!
      --strict               Fail before running if the directory contains any invalid test case.
      --succeed-on-empty     Exit successfully instead of erroring when no test cases are found.

GLOBAL FLAGS
  --flags-dir=<value>  Import flag values from a directory.
  --json               Format output as json.

DESCRIPTION
  Run event test cases in a directory against a target org.

  Discovers event test cases in a directory (the same way the "discover" command does), then executes each valid test
  case against a target org and asserts its response. Looks for the fixed "single" and "list" subdirectories
  (single-event vs list-event payloads), treats each of their subdirectories as an event path, and reads every JSON file
  within as a test case.

  Each test case POSTs its "request" payload to the derived Apex REST endpoint
  (services/apexrest/v1/<event-dir>/<event-path>) and asserts the response status code and, when given, a deep-partial
  match of the response body.

  By default, invalid test cases are skipped and reported at the end; the run proceeds with all valid cases. Use
  --strict to fail the command before running anything if any invalid test case is found. The command exits with a
  non-zero code when any test case fails.

  Invalid hook manifests always abort the run before any test case executes, regardless of --strict: running against
  broken setup or teardown would test an unprepared org. Use --no-hooks to run the test cases without executing (or
  validating) any hooks.

EXAMPLES
  Run all valid test cases in a directory against your default org

    $ sf allvest tests run --source-dir my-e2e-tests/data --target-org my-scratch

  Fail fast if any test case in the directory is invalid

    $ sf allvest tests run --source-dir my-e2e-tests/data --target-org my-scratch --strict

  Run only the test cases for one event path

    $ sf allvest tests run --source-dir my-e2e-tests/data --target-org my-scratch --filter my-event.v1

  Run a particular named test case across every event

    $ sf allvest tests run --source-dir my-e2e-tests/data --target-org my-scratch --filter bare-body

FLAG DESCRIPTIONS
  --[no-]hooks

    Run the enclosing before/after/beforeEach/afterEach hooks (default); use --no-hooks to run the test cases without
    executing (or validating) any hooks.

    Hooks are advanced automations (currently only supports Apex) that are executed before/after the test case. If you
    run this command against a Sandbox
    or Production org, you need to confirm hook execution first or disable hooks with --no-hooks. For CI execution,
    ensure --no-prompt is set.

See code: src/commands/allvest/tests/run.ts