Skip to content
GitHub

TestingModuleOptions

interface in meocord/testing Since 4.0.0

interface TestingModuleOptions

What a testing module is built from: the classes a test needs, and the app whose global stages apply.

Members

controllers

controllers?: (new (...args: any[]) => any)[]

The controllers the module builds, with every class they inject.

providers

providers?: Provider[]

Providers for what those classes inject, in any shape @MeoCord({ providers }) takes.

app Since 4.1.0

app?: new (...args: any[]) => unknown

The @MeoCord app class, whose global guards, interceptors and filters run with each handler's own, and whose translator, presenter, message options, theme, cooldown store and policy, and observers the module uses. A CooldownStore in providers takes the store's place. Its controllers, services and providers are not registered: list the ones a test needs, or build the whole app with MeoCordTestingModule.fromApp.

observers Since 4.1.0

observers?: (new (...args: any[]) => DispatchObserver)[]

@Observer classes told about each call invoke, dispatch and emit make, after the app's own. The module waits for them before a call resolves, so a test sees what they were told.

shutdownTimeout Since 4.1.0

shutdownTimeout?: number

How long close() waits, in milliseconds, for the calls under way, the cooldown store's operations and the onShutdown hooks, as shutdownTimeout in meocord.config.ts bounds the bot's shutdown: from 0 to 2147478647, and 10000 unless set. A test whose fake store never answers, or whose onShutdown never settles, sets it short.

See also