test-sequences.ts

PURPOSE

Pre-built named test sequences consumed by the playground ScenarioRunner. Each sequence is an ordered list of test steps (scenarioId + timeout + speed + optional overrides) that the runner executes back-to-back to validate artifacts, weapons, and stress behavior.

OWNS

  • ARTIFACT_SUITE_T0TestSequence running every artifact scenario from ARTIFACT_TEST_SCENARIOS at tier 0 (default grant).
  • ARTIFACT_SUITE_T3 — same scenario list, with a postStart override injecting a grant_artifact step at tier 3 (legendary). Artifact id derived by stripping the art-test- prefix from the scenario id.
  • WEAPON_DPS_SWEEP — one step per non-disabled weapon in WEAPONS; reuses damage-test scenario and overrides ship.weapons to [{ id, level: 10 }].
  • STRESS_SUITEhorde-peak scenario at speedMult: 1 with world.enemyCountMult cycling through a small set of multipliers.
  • TEST_SEQUENCES — flat array registry of all four sequences above.
  • TEST_SEQUENCE_MAPRecord<string, TestSequence> keyed by seq.id, populated at module load.
  • listTestSequences() — returns the list of registered sequence ids.

READS FROM

  • ./scenario-types — type-only import of TestSequence.
  • ./artifact-scenariosARTIFACT_TEST_SCENARIOS array; one step is emitted per scenario for both artifact suites.
  • ../data/weaponsWEAPONS table, loaded via require() inside a try/catch to dodge a circular-dep load order. The catch swallows the error and leaves _weaponIds as [] (silent empty sweep on failure).
  • Filters WEAPONS by !w.disabled and maps to w.weaponId.

PUSHES TO

Nothing at module scope. Exports are pulled by the playground / ScenarioRunner UI layer to populate sequence pickers and to drive batch runs. Step overrides are passed through to the runner verbatim — this file does not interpret them.

DOES NOT

  • Does not execute steps, time them, or report results — that’s the ScenarioRunner.
  • Does not define scenarios themselves; only references them by scenarioId.
  • Does not validate that referenced scenarios or weapon ids exist.
  • Does not gate on weapon disabled semantics beyond the boolean filter.
  • Does not surface the require() failure — silently empties the weapon sweep.

Signals

None. Pure data module; no events, no store writes, no telemetry.

Entry points

  • Module-level constant exports (ARTIFACT_SUITE_T0, ARTIFACT_SUITE_T3, WEAPON_DPS_SWEEP, STRESS_SUITE, TEST_SEQUENCES, TEST_SEQUENCE_MAP).
  • listTestSequences() for UI enumeration.

Pattern notes

  • Circular-dep dodge via require() + try/catch. The weapon list is loaded lazily through CommonJS require to avoid an ESM import cycle. The empty catch is a deliberate silent fallback — at boundary with the data module, but note this violates the “crash on bad data” preference for internal failures. If WEAPONS ever fails to load, WEAPON_DPS_SWEEP becomes a no-op with no warning.
  • Convention coupling — art-test-<artifactId>. ARTIFACT_SUITE_T3 synthesizes the artifact id by stripping the art-test- prefix from each scenario id. Renaming artifact scenarios in artifact-scenarios.ts without preserving this prefix will silently grant the wrong artifact (or nothing).
  • Step speedMult vs sequence defaultSpeed. Both are set on artifact and weapon sequences; stress suite uses speedMult: 1 on every step and defaultSpeed: 1 to keep timing realistic under load.
  • as const on override step types. grant_artifact is narrowed to a literal in the postStart override array so the override conforms to the discriminated union expected by the runner.
  • Registry is built once at module load. TEST_SEQUENCE_MAP is populated by a top-level for loop, not lazily — adding a sequence requires appending to the TEST_SEQUENCES array.

EXTRACT-CANDIDATE

  • The silent try/catch around require('../data/weapons') is a recurring pattern in playground/testing code to dodge load-order issues. If it shows up elsewhere, extract a shared tryRequire<T>(path, fallback) helper with a single logging policy (or, preferred per project rules, replace with a properly ordered import and remove the fallback).
  • The art-test-<id> prefix convention is implicit shared knowledge between artifact-scenarios.ts and this file. Worth lifting to a single named constant + helper (artifactIdFromScenarioId) in scenario-types.ts so the coupling is explicit and grep-able.