Testing

36 symbols from @neontechspace/fluxerly/effect/testing

Functions#

`createTestBot`#

Create a test client that runs a bot written for the native runBot: Its events, ignoreBots setting, commands and setup Effect, with the same handler contexts, delivery defaults and command router as runBot

Pass the bot's own options object: Its signal, processSignals, reportFailure and drainMs settings are ignored, an undefined token uses the fixture token, and transport and instance belong to the test client. Handlers and commands are registered when the Effect runs, and ready runs setup before connecting, as runBot does. The creating Scope cleans the client up, as with createTestClient. Automatic gateway filtering sees the bot's handlers, commands and setup registrations, and emit dies for dispatches that list suppresses

createTestBot<
    F extends MessageFields | undefined = undefined,
    Events extends BotEvents<unknown, unknown, SelectedMessage<F>>
        = BotEvents<unknown, unknown, SelectedMessage<F>>,
    S extends Readonly<Record<string, unknown>> = { … },
    C extends Readonly<
        Record<
            keyof S,
            {
                readonly arguments?: Readonly<
                    Record<string, CommandArgumentDescriptor>
                >
                readonly execute: unknown
            }
        >
    >
        = Readonly<
            Record<
                keyof S,
                {
                    readonly arguments?: Readonly<
                        Record<string, CommandArgumentDescriptor>
                    >
                    readonly execute: unknown
                }
            >
        >,
    RouterServices = never,
    OptionsError = never,
    OptionsServices = never,
    SetupServices = never,
    ReadyServices = never
>(
    options:
        & Omit<
              TestClientOptions<OptionsError, OptionsServices, F>,
              "token"
          >
        & {
              readonly commands?: BotCommandsOptions<
                  SelectedMessage<F>, S, C, RouterServices,
                  ReadyServices
              >
              readonly drainMs?: number
              readonly events?:
                  & Events
                  & Record<
                        Exclude<
                            keyof Events,
                            keyof EventMap<Message>
                        >,
                        never
                    >
              readonly ignoreBots?: boolean
              readonly processSignals?: boolean
              readonly reportFailure?: boolean
              readonly setup?: (client: Client<SelectedMessage<F>>)
                  => Effect<unknown, unknown, SetupServices>
              readonly signal?: unknown
              readonly token?: string
          }
): Effect<
    TestBot<SelectedMessage<F>>,
    ApplicationError,
    | Scope
    | Exclude<RouterServices, Scope>
    | Exclude<OptionsServices, Scope>
    | Exclude<SetupServices, Scope>
    | Exclude<ReadyServices, Scope>
    | Exclude<BotEventServices<Events>, Scope>
    | Exclude<BatchRequirements<C>, Scope>
>createTestBot<
  F extends
    | MessageFields | undefined
    = undefined,
  Events extends BotEvents<
    unknown, unknown,
    SelectedMessage<F>
  >
    = BotEvents<
      unknown, unknown,
      SelectedMessage<F>
    >,
  S extends Readonly<
    Record<string, unknown>
  >
    = { … },
  C extends Readonly<
    Record<
      keyof S,
      {
        readonly arguments?: Readonly<
          Record<
            string,
            CommandArgumentDescriptor
          >
        >
        readonly execute: unknown
      }
    >
  >
    = Readonly<
      Record<
        keyof S,
        {
          readonly arguments?: Readonly<
            Record<
              string,
              CommandArgumentDescriptor
            >
          >
          readonly execute: unknown
        }
      >
    >,
  RouterServices = never,
  OptionsError = never,
  OptionsServices = never,
  SetupServices = never,
  ReadyServices = never
>(
  options:
    & Omit<
        TestClientOptions<
          OptionsError,
          OptionsServices, F
        >,
        "token"
      >
    & {
        readonly commands?: BotCommandsOptions<
          SelectedMessage<F>, S, C,
          RouterServices,
          ReadyServices
        >
        readonly drainMs?: number
        readonly events?:
          & Events
          & Record<
              Exclude<
                keyof Events,
                keyof EventMap<Message>
              >,
              never
            >
        readonly ignoreBots?:
          boolean
        readonly processSignals?:
          boolean
        readonly reportFailure?:
          boolean
        readonly setup?: (
          client: Client<
            SelectedMessage<F>
          >
        ) => Effect<
          unknown, unknown,
          SetupServices
        >
        readonly signal?: unknown
        readonly token?: string
      }
): Effect<
  TestBot<SelectedMessage<F>>,
  ApplicationError,
  | Scope
  | Exclude<RouterServices, Scope>
  | Exclude<OptionsServices, Scope>
  | Exclude<SetupServices, Scope>
  | Exclude<ReadyServices, Scope>
  | Exclude<
      BotEventServices<Events>,
      Scope
    >
  | Exclude<
      BatchRequirements<C>, Scope
    >
>

Parameters

options: & Omit<TestClientOptions<OptionsError, OptionsServices, F>, "token"> & { readonly commands?: BotCommandsOptions< SelectedMessage<F>, S, C, RouterServices, ReadyServices > readonly drainMs?: number readonly events?: & Events & Record< Exclude<keyof Events, keyof EventMap<Message>>, never > readonly ignoreBots?: boolean readonly processSignals?: boolean readonly reportFailure?: boolean readonly setup?: (client: Client<SelectedMessage<F>>) => Effect<unknown, unknown, SetupServices> readonly signal?: unknown readonly token?: string }& Omit< TestClientOptions< OptionsError, OptionsServices, F >, "token" > & { readonly commands?: BotCommandsOptions< SelectedMessage<F>, S, C, RouterServices, ReadyServices > readonly drainMs?: number readonly events?: & Events & Record< Exclude< keyof Events, keyof EventMap<Message> >, never > readonly ignoreBots?: boolean readonly processSignals?: boolean readonly reportFailure?: boolean readonly setup?: ( client: Client<SelectedMessage<F>> ) => Effect< unknown, unknown, SetupServices > readonly signal?: unknown readonly token?: string }

Returns: Effect< TestBot<SelectedMessage<F>>, ApplicationError, | Scope | Exclude<RouterServices, Scope> | Exclude<OptionsServices, Scope> | Exclude<SetupServices, Scope> | Exclude<ReadyServices, Scope> | Exclude<BotEventServices<Events>, Scope> | Exclude<BatchRequirements<C>, Scope> >Effect< TestBot<SelectedMessage<F>>, ApplicationError, | Scope | Exclude<RouterServices, Scope> | Exclude<OptionsServices, Scope> | Exclude<SetupServices, Scope> | Exclude<ReadyServices, Scope> | Exclude< BotEventServices<Events>, Scope > | Exclude< BatchRequirements<C>, Scope > >
Fails with: ApplicationError

Invalid options die with ConfigurationError, as in runBot, and a commands register callback that throws fails with its ApplicationError. The services that handlers, commands and setup need are required by this Effect. The runBot supervision of a stopped subscription does not apply in tests

TypeScript

import { Effect } from "effect"
import { createTestBot } from "@neontechspace/fluxerly/effect/testing"

export const pingTest = Effect.scoped(
    Effect.gen(function* () {
        const test = yield* createTestBot({
            commands: { prefix: "!", commands: { ping: { execute: ({ reply }) => reply("Pong!") } } },
        })
        yield* test.ready()
        // The test transport answers the reply with an echoed message, so no rest.respond fixture is needed
        return yield* test.say("!ping")
    }),
)

`createTestClient`#

Create a real native client wired to an in-memory Fluxer for application tests, owned by the caller's Scope

Creation opens no connection and starts no timers. Run ready to connect. Closing the scope shuts the client down and closes the test transport. The gateway enforces gateway.ignoredEvents, so register handlers before ready when automatic filtering is enabled

createTestClient<
    E = never,
    R = never,
    F extends MessageFields | undefined = undefined
>(
    options?: TestClientOptions<E, R, F>
): Effect<TestClient<SelectedMessage<F>>, never, Scope | R>createTestClient<
  E = never,
  R = never,
  F extends
    | MessageFields | undefined
    = undefined
>(
  options?:
    TestClientOptions<E, R, F>
): Effect<
  TestClient<SelectedMessage<F>>,
  never,
  Scope | R
>

Parameters

options optional: TestClientOptions<E, R, F>

Returns: Effect<TestClient<SelectedMessage<F>>, never, Scope | R>Effect< TestClient<SelectedMessage<F>>, never, Scope | R >

Invalid options are a defect carrying ConfigurationError, as with createClient, and supplying transport or instance is too, because the test transport owns both. The hint for a misspelled key suggests the closest key a test client accepts

TypeScript

import { Effect, Fiber } from "effect"
import { createTestClient } from "@neontechspace/fluxerly/effect/testing"

export const greetingTest = Effect.scoped(
    Effect.gen(function* () {
        const test = yield* createTestClient({ cache: { members: true } })
        yield* test.ready()
        const joined = yield* Effect.forkScoped(test.client.waitFor("guildMemberAdd"))
        yield* Effect.yieldNow
        yield* test.emit("GUILD_MEMBER_ADD", test.fixtures.member())
        return yield* Fiber.join(joined)
    }),
)

Classes#

FluxerTestClient: Effect service holding a native test client, for applications whose code reads the client from the FluxerClient service

Interfaces#

`TestBot`#

A native test client running a bot written for runBot

It is a TestClient whose ready first runs the bot's setup, with say to talk to the bot as a user would

interface TestBot<M extends MessageCore = Message>
    extends Omit<TestClient<M>, "ready">interface TestBot<
  M extends MessageCore = Message
>
  extends Omit<
    TestClient<M>, "ready"
  >

client#: The client under test, created with the native createClient

Use it exactly as in the application
Client<M>
fixtures#: A fixture set of its own, whose IDs do not depend on other tests

READY reports its botUser() by default
Fixtures
rest#: Register the HTTP responses the fake Fluxer API returns
TestRest

`commands`#

Gateway commands the client sent so far, in order, with tokens redacted

commands(): readonly TestGatewayCommand[]

Returns: readonly TestGatewayCommand[]

`counters`#

The client's running totals, the same as client.diagnostics().counters

counters(): ClientCounters

Returns: ClientCounters

`disconnect`#

Close one shard's connection from the gateway side with a close code when run

The SDK then recovers as it would against Fluxer, resuming with RESUMED for a resumable code, or ends the connection lifetime for a fatal one. With endSession set, the client identifies a new session instead of resuming. Dies with ConfigurationError when that shard is not connected

disconnect(options?: TestDisconnectOptions): Effect<void>disconnect(
  options?: TestDisconnectOptions
): Effect<void>

Parameters

options optional: TestDisconnectOptions

Returns: Effect<void>

`emit`#

Deliver one gateway dispatch to a connected shard when run, with the next sequence number

The type is the Fluxer wire dispatch name, such as MESSAGE_CREATE or GUILD_MEMBER_ADD, and the payload is the wire body in snake_case, so it passes through the SDK's real decoders, cache updates and handlers. With the client's cache option enabled, handlers receive EventContext.previous exactly as against Fluxer, and every accepted dispatch advances client.lastReceipt. Handlers run afterwards on their own schedule. Start client.waitFor before emitting to await delivery. Unknown types are delivered too unless explicitly suppressed, and malformed payloads follow the client's gateway.onMalformedDispatch policy. Dies with ConfigurationError without consuming a sequence when the session's Identify filtering would suppress the dispatch. Suppressed MESSAGE_CREATE still arrives for a direct bot mention, @here or @everyone. Role-only mentions, direct-message delivery and bot authorship alone do not exempt it. Generated MESSAGE_REACTION_ADD_MANY is gated by MESSAGE_REACTION_ADD, not its generated name. Register handlers before ready when gateway.ignoredEvents is "auto", or remove the source type from the explicit list (use [] to disable suppression). Resume keeps the list. READY and RESUMED are reserved for the handshake. Dies with ConfigurationError before ready or for a shard this client does not own

emit(
    type: string,
    payload: unknown,
    options?: TestEmitOptions
): Effect<void>emit(
  type: string,
  payload: unknown,
  options?: TestEmitOptions
): Effect<void>

Parameters

type: string
payload: unknown
options optional: TestEmitOptions

Returns: Effect<void>

`failures`#

Error records of failures no application code handled so far, in order, such as an event handler, command or client.schedule task run that failed while no onError hook was registered, whether the error came from the application or from a Fluxer rejection

Assert expected failures here, because shutdown fails for unhandled failures that failures() has not returned. Failures are captured whatever the logging level, categories and deduplication, so each one appears here and counts for shutdown even when logs() leaves it out

failures(): readonly LogRecord[]

Returns: readonly LogRecord[]

`idle`#

Succeed once the client has settled: No event handler or command is running or has a received event waiting for it, no client.schedule task run is running, no REST request is queued or waiting for its test response, and no new log record, request or gateway command appeared for a few event loop turns

Run it after emit to assert that the bot did nothing, or before inspecting results. Open waits and collectors do not count as work, and onError hooks are not awaited. A scheduled task waiting for its time does not count either, so advance the clock that drives the client's timers to run it. Without timeoutMs the wait has no SDK deadline, so the test runner's own timeout ends a test whose client never settles. With timeoutMs it fails with TestTimeoutError when the client is still busy after it. It dies with ClientClosedError after shutdown. Invalid options are a defect carrying ConfigurationError. The wait's own timers, including timeoutMs, stay real when a test fakes timers. The SDK runs on setImmediate, so fake timers must leave it real, otherwise idle dies with ConfigurationError instead of settling while no handler can run

idle(options?: TestWaitOptions): Effect<void, TestTimeoutError>idle(
  options?: TestWaitOptions
): Effect<void, TestTimeoutError>

Parameters

options optional: TestWaitOptions

Returns: Effect<void, TestTimeoutError>
Fails with: TestTimeoutError

`logs`#

Log records the client produced so far, in order, at the logging option's level and categories, default Info

The records also reach any sinks in the logging option. Nothing reaches the Effect logger

logs(): readonly LogRecord[]

Returns: readonly LogRecord[]

`ready`#

Run the bot's setup Effect once, then connect to the test gateway and succeed once every shard it owns is READY

Running it again runs setup no more and succeeds without opening another socket while connected. A failed setup fails with ApplicationError whose source is "runBot setup", before connecting, and a failed connection fails with its connect failure

ready(): Effect<void, ApplicationError | ConnectError>ready(): Effect<
  void,
  ApplicationError | ConnectError
>

Returns: Effect<void, ApplicationError | ConnectError>Effect< void, ApplicationError | ConnectError >
Fails with: ApplicationError
ConnectError

`requests`#

HTTP requests the client sent so far, in order, excluding the discovery bootstrap and without credentials

requests(): readonly TestRequest[]

Returns: readonly TestRequest[]

`say`#

Deliver a message with this content from a human user, wait until the bot has settled as idle does, and succeed with the messages the bot sent meanwhile, in send order, or an empty list when it sent nothing

Run ready first. Each entry is a message send (POST /channels/:id/messages) in wire shape, built from the request body with the fields the automatic reply echoes, so it shows what the bot sent even when a rest.respond handler answered. Edits, reactions and other requests are not included, and remain visible through requests(). The message comes from the fixture set's default human author in its default channel and community, and options.message replaces any of those wire fields. The content is normalized as Fluxer normalizes sent text, without form feed (U+000C) or U+202E and with surrounding whitespace trimmed, so "!ping " arrives as "!ping". Use emit with fixtures.message to deliver content unchanged. Like idle, say has no deadline unless options.timeoutMs is set, then fails with TestTimeoutError when the bot is still busy after it, and dies with ClientClosedError after shutdown. It dies with ConfigurationError for content that is not a string, invalid options, before ready and when gateway filtering would suppress the message, as emit does

say(
    content: string,
    options?: TestSayOptions
): Effect<readonly WireMessage[], TestTimeoutError>say(
  content: string,
  options?: TestSayOptions
): Effect<
  readonly WireMessage[],
  TestTimeoutError
>

Parameters

content: string
options optional: TestSayOptions

Returns: Effect<readonly WireMessage[], TestTimeoutError>Effect< readonly WireMessage[], TestTimeoutError >
Fails with: TestTimeoutError

TypeScript

import { Effect } from "effect"
import { createTestBot } from "@neontechspace/fluxerly/effect/testing"

export const sayTest = Effect.scoped(
    Effect.gen(function* () {
        const test = yield* createTestBot({
            commands: { prefix: "!", commands: { ping: { execute: ({ reply }) => reply("Pong!") } } },
        })
        yield* test.ready()
        const replies = yield* test.say("!ping")
        return replies.map((message) => message.content)
    }),
)

`shutdown`#

Shut the client down, then close the test transport

It fails with UnhandledTestFailuresError when application code failed without a handler and failures() did not return that failure, so a broken handler fails the test. Each failure is reported once, so running it again succeeds. Closing the creating scope does the same, and dies with UnhandledTestFailuresError for failures not reported yet

shutdown(): Effect<void, UnhandledTestFailuresError>shutdown(): Effect<
  void,
  UnhandledTestFailuresError
>

Returns: Effect<void, UnhandledTestFailuresError>Effect< void, UnhandledTestFailuresError >
Fails with: UnhandledTestFailuresError

`TestClient`#

A real native client connected to an in-memory Fluxer, with controls for driving and inspecting it

Control misuse, such as emitting before ready, is a defect carrying ConfigurationError, and use after shutdown is a defect carrying ClientClosedError

interface TestClient<M extends MessageCore = Message>interface TestClient<
  M extends MessageCore = Message
>

client#: The client under test, created with the native createClient

Use it exactly as in the application
Client<M>
fixtures#: A fixture set of its own, whose IDs do not depend on other tests

READY reports its botUser() by default
Fixtures
rest#: Register the HTTP responses the fake Fluxer API returns
TestRest

`commands`#

Gateway commands the client sent so far, in order, with tokens redacted

commands(): readonly TestGatewayCommand[]

Returns: readonly TestGatewayCommand[]

`counters`#

The client's running totals, the same as client.diagnostics().counters

counters(): ClientCounters

Returns: ClientCounters

`disconnect`#

Close one shard's connection from the gateway side with a close code when run

disconnect(options?: TestDisconnectOptions): Effect<void>disconnect(
  options?: TestDisconnectOptions
): Effect<void>

Parameters

options optional: TestDisconnectOptions

Returns: Effect<void>

`emit`#

Deliver one gateway dispatch to a connected shard when run, with the next sequence number

emit(
    type: string,
    payload: unknown,
    options?: TestEmitOptions
): Effect<void>emit(
  type: string,
  payload: unknown,
  options?: TestEmitOptions
): Effect<void>

Parameters

type: string
payload: unknown
options optional: TestEmitOptions

Returns: Effect<void>

`failures`#

failures(): readonly LogRecord[]

Returns: readonly LogRecord[]

`idle`#

idle(options?: TestWaitOptions): Effect<void, TestTimeoutError>idle(
  options?: TestWaitOptions
): Effect<void, TestTimeoutError>

Parameters

options optional: TestWaitOptions

Returns: Effect<void, TestTimeoutError>
Fails with: TestTimeoutError

`logs`#

Log records the client produced so far, in order, at the logging option's level and categories, default Info

The records also reach any sinks in the logging option. Nothing reaches the Effect logger

logs(): readonly LogRecord[]

Returns: readonly LogRecord[]

`ready`#

Connect the client to the test gateway and succeed once every shard it owns is READY, like client.connect

Running it again while connected succeeds without opening another socket. With gateway.ignoredEvents set to "auto", register handlers before running this Effect, because Identify chooses filtering from those registrations. It fails with the connect failure, such as ConnectionError when a handler closed the connection

ready(): Effect<void, ConnectError>

Returns: Effect<void, ConnectError>
Fails with: ConnectError

`requests`#

HTTP requests the client sent so far, in order, excluding the discovery bootstrap and without credentials

requests(): readonly TestRequest[]

Returns: readonly TestRequest[]

`shutdown`#

Shut the client down, then close the test transport

shutdown(): Effect<void, UnhandledTestFailuresError>shutdown(): Effect<
  void,
  UnhandledTestFailuresError
>

Returns: Effect<void, UnhandledTestFailuresError>Effect< void, UnhandledTestFailuresError >
Fails with: UnhandledTestFailuresError

`TestRest`#

Without a registration, message sends (POST /channels/:id/messages) and edits (PATCH /channels/:id/messages/:id) receive an automatic reply: A message by the bot account that echoes the request's content, embeds, flags and tts, with a new fixture ID for a send and the edited ID for an edit. Other unmatched requests receive a Fluxer-shaped 404. The echoed content is normalized as Fluxer stores it, without form feed (U+000C) or U+202E and with surrounding whitespace trimmed

interface TestRest

`respond`#

Answer matching requests with a fixed response or a handler's response until the registration is removed

The newest matching registration wins, including over the automatic message replies. Invalid matchers or responses throw ConfigurationError

respond(
    matcher: TestRequestMatcher,
    response: TestResponse | TestResponder
): TestRouterespond(
  matcher: TestRequestMatcher,
  response:
    | TestResponse | TestResponder
): TestRoute

Parameters

matcher: TestRequestMatcher
response: TestResponse | TestResponder

Returns: TestRoute

TypeScript

import { createTestClient } from "@neontechspace/fluxerly/effect/testing"
import { Effect } from "effect"

export const respondExample = Effect.gen(function* () {
    const test = yield* createTestClient()
    test.rest.respond("GET /users/@me", { body: test.fixtures.botUser() })
    return test.rest.respond("POST /channels/:id/messages", (request) => ({
        body: test.fixtures.message({ content: String((request.body as { content?: unknown }).content) }),
    }))
})

`TestRoute`#

One registered response of a native test client

Registrations are searched newest first, so a later registration overrides an earlier one for the requests both match

interface TestRoute

`next`#

Succeed with the next request this registration answers

Each run returns a different request, in order, so a request that arrived before the run is returned at once. Without timeoutMs the wait has no SDK deadline, so the test runner's own timeout ends a test whose request never arrives. With timeoutMs it fails with TestTimeoutError when no request arrives in time. It dies with ClientClosedError when the test client shuts down first, and interruption ends the wait. Invalid options are a defect carrying ConfigurationError

next(
    options?: TestWaitOptions
): Effect<TestRequest, TestTimeoutError>next(
  options?: TestWaitOptions
): Effect<
  TestRequest, TestTimeoutError
>

Parameters

options optional: TestWaitOptions

Returns: Effect<TestRequest, TestTimeoutError>
Fails with: TestTimeoutError

`remove`#

Stop answering requests

Earlier matching registrations apply again. Without a match, message sends and edits receive automatic message replies, and other requests receive the default 404

remove(): void

`requests`#

Requests this registration answered so far, in order

requests(): readonly TestRequest[]

Returns: readonly TestRequest[]

Type Aliases#

`TestClientOptions`#

Options for createTestClient: Every native createClient option except token, transport and instance, plus test settings

The token defaults to the fixture token, the transport is always the in-memory test transport and the instance is always hosted Fluxer served from memory

type TestClientOptions<
    E = never,
    R = never,
    F extends MessageFields | undefined = undefined
> =
    & Omit<
          ClientOptions<E, R, F>,
          "token" | "transport" | "instance"
      >
    & TestSettingstype TestClientOptions<
  E = never,
  R = never,
  F extends
    | MessageFields | undefined
    = undefined
> =
  & Omit<
      ClientOptions<E, R, F>,
      | "token" | "transport"
      | "instance"
    >
  & TestSettings

Re-Exports#

Declared in Testing and documented there. Import them from @neontechspace/fluxerly/effect/testing as well

createFixtures#: Create an independent fixture set whose ID sequence starts from the beginning
fixtureToken#: A token-shaped value used by test clients by default
fixtures#: A shared fixture set for quick payloads
TestTimeoutError#: A test wait, such as TestRoute.next, idle or say, did not finish within the timeoutMs the test passed
UnhandledTestFailuresError#: A test client shut down after application code failed without a handler, such as an event handler or command that threw or returned a failed Result
Fixtures#: A set of wire payload builders sharing one deterministic ID sequence
TestDisconnectOptions#: Choose how the test gateway ends one shard's connection
TestEmitOptions#: Choose the shard that receives an emitted dispatch
TestGatewayCommand#: One gateway command a client sent to the test gateway, in send order
TestRequest#: One HTTP request a test client sent, as recorded by the test transport and passed to response handlers
TestRequestFile#: One attachment part of a recorded multipart request
TestSayOptions#: Choose the message a test bot's say delivers and how long say waits for the bot to settle
TestSettings#: Settings that only test clients accept, alongside the usual client options
TestWaitOptions#: Limit how long a test wait, such as TestRoute.next, idle or say, may take
WireChannel#: A community channel in the wire shape of channel reads and channel events
WireForumChannel#: A forum or media channel in the wire shape of channel reads and channel events
WireGuild#: A community record in the wire shape of guild reads, GUILD_UPDATE and the properties of GUILD_CREATE
WireGuildCreate#: A complete GUILD_CREATE dispatch body: The community ready object with its roles, channels, threads and members
WireMember#: A community membership in the wire shape of GUILD_MEMBER_ADD and GUILD_MEMBER_UPDATE
WireMessage#: A message in the wire shape of message reads, MESSAGE_CREATE and MESSAGE_UPDATE
WireRole#: A community role in the wire shape of role reads and role events
WireThread#: A thread in the wire shape of thread reads, thread lists and THREAD_CREATE and THREAD_UPDATE
WireUser#: A public Fluxer account in the wire shape used by message authors, members and user reads
TestRequestMatcher#: Select the requests a registered response answers
TestResponder#: Compute a response from the recorded request
TestResponse#: A response description
WireGuildCreateOverrides#: Overrides for a GUILD_CREATE fixture
WireOverrides#: Wire-field overrides for a fixture builder

Testing

Functions#

createTestBot#

createTestClient#

Classes#

Interfaces#

TestBot#

commands#

counters#

disconnect#

emit#

failures#

idle#

logs#

ready#

requests#

say#

shutdown#

TestClient#

commands#

counters#

disconnect#

emit#

failures#

idle#

logs#

ready#

requests#

shutdown#

TestRest#

respond#

TestRoute#

next#

remove#

requests#

Type Aliases#

TestClientOptions#

Re-Exports#

`createTestBot`#

`createTestClient`#

`TestBot`#

`commands`#

`counters`#

`disconnect`#

`emit`#

`failures`#

`idle`#

`logs`#

`ready`#

`requests`#

`say`#

`shutdown`#

`TestClient`#

`commands`#

`counters`#

`disconnect`#

`emit`#

`failures`#

`idle`#

`logs`#

`ready`#

`requests`#

`shutdown`#

`TestRest`#

`respond`#

`TestRoute`#

`next`#

`remove`#

`requests`#

`TestClientOptions`#