Appearance
Testing
FlowPad's tests live outside the package — in the matrix-3 repo's shared tests/ tree. The package only ships package.json script entries that invoke the workspace test runner.
Test commands (from projects/matrix-3/packages/flowpad/package.json)
jsonc
"scripts": {
"test": "cd ../.. && tsx scripts/test.ts --timeout 30000 tests/unit/flowpad-v2/**/*.spec.ts tests/integration/flowpad-v2/**/*.spec.ts",
"test:ci": "cd ../.. && tsx scripts/test.ts --timeout 30000 tests/unit/flowpad-v2/**/*.spec.ts",
"test:unit":"tsx --test tests/unit/**/*.spec.ts",
"type-check":"tsc --noEmit"
}pnpm --filter @open-matrix/flowpad test runs both unit and integration tests with a 30s timeout. test:ci runs only unit specs (faster, sufficient for change-detection gating).
Unit tests
projects/matrix-3/tests/unit/flowpad-v2/:
execution-status-topology.spec.ts—resolveExecutionTopologyfixture-based tests. Covers the topology summary string when authority/runtime/platform roots vary, and when a requested root is unavailable.test-runner.spec.ts— exercises the unit-test harness for FlowPad's runtime helpers.
These run via Node's --test mode. They do not start a browser; they import the source modules directly.
Integration tests
projects/matrix-3/tests/integration/flowpad-v2/:
headless-runner.spec.ts— boots a FlowPad runtime headlessly (no DOM), mounts services, and runs DSL examples end-to-end against the in-memory transport. This catches regressions incompileSourceToCanonicalIRandexecuteCanonicalIR.project-loader.spec.ts— coversshell/projectCatalog.ts: manifest parsing, dependency topo-sort, alias resolution, and validation of malformed manifests.
End-to-end (Playwright)
projects/matrix-3/tests/e2e/:
flowpad-functional.spec.ts— drives the rendered FlowPad page through Playwright. Asserts that the editor accepts input, the run button executes, results appear, and transport messages are logged.flowpad-buttons.spec.ts— focused checks on the toolbar buttons (Run, Clear, copy mount tag).dogfood-flow.spec.ts— bigger scenario combining FlowPad, the catalog, and a target actor.e2e-flowpad-daemon.spec.ts— covers the historical daemon-routed run mode. Note: this exercises the retiredmatrixdpath; it is kept as a regression guard but new product runs go throughhivecast startand the Host Service.e2e-cli-prompt-flowpad.spec.ts— tests CLI-driven prompts that target FlowPad as$TARGET.e2e-security-flowpad.spec.ts— exercises the security-realm DSL examples.e2e-runtime-control-flow-roundtrip.node.ts+.LOG.md— runtime-control-flow round-trip; the.LOG.mdcompanion captures expected output.
End-to-end tests require a built dist/ (Pattern: rebuild before testing — see project rules). The recipe:
bash
pnpm --filter @open-matrix/flowpad build
pnpm --filter @open-matrix/flowpad test
# Then:
cd projects/matrix-3
npx playwright test tests/e2e/flowpad-functional.spec.tsType checking
pnpm --filter @open-matrix/flowpad type-check runs tsc --noEmit against projects/matrix-3/packages/flowpad/tsconfig.json. The package is required to be --strict clean per project Rule 9.
What the tests do not cover
- Real cross-Host federation. The integration tests use the in-memory transport; the federated NATS path is exercised by
tests/e2e/only. - The COM Bridge example flows (
'COM: ...'examples indsl/examples.ts). They require a Windows host and a runningcom-bridgedaemon. - Real LLM-driven flows. The
'Agent: ...'examples assume a connected inference service; CI runs them only with mocks.
CI gating
The five-gate pre-merge gate (scripts/ci/premerge-local.sh, see project CLAUDE.md) runs FlowPad's test:ci, type-check, and the package-boundary guard. Anything tagged with the harvest watchlist (e.g. cross-package ../../ imports) fails the gate before merge.
See also
Source:
projects/matrix-3/packages/flowpad/package.jsonscripts;projects/matrix-3/tests/unit/flowpad-v2/,projects/matrix-3/tests/integration/flowpad-v2/,projects/matrix-3/tests/e2e/flowpad-*.