# Testing — Systems Deep Dive

> The `testing/` directory: two tracked Nx projects that own the monorepo's
> shared cross-domain test infrastructure — reusable utilities, fixtures, mocks,
> e2e/integration/performance/chaos harnesses, and a dedicated Bellona
> remote-control mock harness.

## What this area is

This area is the monorepo's **shared test-infrastructure root**, rooted at the
top-level `testing/` directory rather than under `libs/`. It is not one domain's
tests; it is the cross-cutting tooling that any app or library can import to
write tests consistently. Two Nx projects live here: a single large umbrella
library, `@oshun/testing-infra`, whose `sourceRoot` is the whole `testing/` tree
(`testing/project.json`), and one nested, separately-named project,
`@bellona/remote-control-testing`
(`testing/bellona/remote-control/project.json`), which is a focused mock harness
for the Bellona remote-control protocol.

`@oshun/testing-infra` is broad. Its barrel `testing/index.ts` re-exports Vitest
primitives plus the shared utility and fixture modules, but the project's
`sourceRoot` covers far more than that barrel: reusable helpers
(`testing/utils/test-utils.ts`, `http-utils.ts`, `database-utils.ts`), a large
fixture library (`testing/fixtures/index.ts` with per-domain factories for
Yemaya/Lilith/Isis/Sophia/Hathor/Bellona), module mocks (`testing/mocks/` —
Prisma client, `three.js` loaders, `lz4`, `rbxm-parser`), consumer-driven
contract testing (`testing/integration/contract-testing.ts`), Playwright e2e
with a page-object model (`testing/e2e/`), Detox mobile e2e (`testing/mobile/`),
k6 + Vitest performance benchmarks (`testing/performance/`), chaos suites
(`testing/chaos/aphrodite/`), a module-boundary validator
(`testing/boundary/validate-boundaries.ts`), shared Vitest setup/config files
(`testing/setup/`, `testing/vitest.config.*.ts`, `testing/templates/`), and the
Nx targets that run each surface (`test`, `test:integration`, `test:e2e`,
`test:performance`).

The two projects are related by directory but technically independent:
`@bellona/remote-control-testing` is its own Nx project with its own
`package.json`, `tsconfig.lib.json`, and `vitest.config.ts`, tagged
`scope:bellona`. It does not depend on `@oshun/testing-infra`; its only
workspace dependency is `@bellona/remote-protocol` (the canonical protocol
contracts it validates fixtures against). It lives under `testing/` because it
is test-only code, but it is scoped to Bellona's Phase 180 remote-control work
rather than being shared infrastructure.

## How it fits the wider system

`@oshun/testing-infra` is consumed across the monorepo: app and library test
suites import its utilities and fixtures, the e2e page objects drive the web
shells under Playwright, the integration harness verifies cross-domain HTTP
contracts, and the `boundary/validate-boundaries.ts` gate enforces the same
cross-domain import baselines that the ESLint `@nx/enforce-module-boundaries`
rule and `tests/security/new-structure.security.test.ts` track. Note that the
Playwright page objects import from a separate published `@oshun/testing`
package (e.g. `@oshun/testing/playwright` in
`testing/e2e/page-objects/base.page.ts`), which is distinct from this
`@oshun/testing-infra` project — the two names are easy to confuse but are
different packages.

`@bellona/remote-control-testing` is consumed by Bellona gateway, host, MCP, and
adapter work as a ready-made set of in-memory transports and release gates, so
those surfaces do not rebuild mock transports or re-derive Phase 180 release
checklists. It composes strictly with `@bellona/remote-protocol`: every fixture
and replay cassette it produces is validated against that package's Zod schemas
(e.g. `RemoteCommandEnvelopeSchema`), and it deliberately stops at the
deterministic-fixture boundary — its deployment, network, security, and
performance suites are honest about being fixture evidence that does not replace
live two-MacBook, cloud, WebRTC/TURN, or hardware evidence.

## Entity reference

### @oshun/testing-infra

The monorepo's shared, cross-domain test-infrastructure library, rooted at the
whole `testing/` tree (`sourceRoot: "testing"` in `testing/project.json`,
package `@oshun/testing-infra`, tagged `layer:test-infra`). It is a real,
substantial implementation — not a scaffold — comprising typed mock factories
and async/error/env helpers (`testing/utils/test-utils.ts`), a per-domain
fixture factory library with a generic `FixtureFactory` class
(`testing/fixtures/index.ts`), module mocks under `testing/mocks/`, a
consumer-driven contract registry and verifier
(`testing/integration/contract-testing.ts`), a Playwright page-object e2e suite
(`testing/e2e/`), Detox mobile e2e (`testing/mobile/`), k6 and Vitest
performance benchmarks (`testing/performance/`), Aphrodite chaos suites
(`testing/chaos/aphrodite/`), and a module-boundary validator that enforces a
baseline of allowed cross-domain imports
(`testing/boundary/validate-boundaries.ts`). The barrel `testing/index.ts`
exposes the utility/fixture surface and re-exports Vitest, while the project's
Nx `targets` wire `test`, `test:integration`, `test:e2e`, and `test:performance`
to the corresponding Vitest/Playwright configs. The fixtures and helpers
intentionally use `Math.random()` for non-deterministic test data (annotated
`random:legitimate test fixture` in `test-utils.ts`) — appropriate for fixture
generation, not faked computation.

### @bellona/remote-control-testing

A test-only mock harness and protocol-fixture library for Bellona's Phase 180
remote-control work (`testing/bellona/remote-control/`, package
`@bellona/remote-control-testing`, tags `scope:bellona`,
`surface:remote-control`). It is fully implemented: the barrel `index.ts`
re-exports ~18 modules, and its README enumerates the public surface. The core
is a set of in-memory fakes — `FakeGatewayTransport`, `FakeHostAdapter`,
`FakeMcpClientTransport`, plus `Mock*` device/adapter/host/gateway objects —
that exercise host registration, command dispatch, idempotency, policy/approval
decisions, audit emission, and progress aggregation without opening sockets or
touching Blender, Unreal, Chrome, or WebRTC. It imports the canonical
`@bellona/remote-protocol` contracts (`RemoteCommandEnvelopeSchema`,
`createRemoteCommandError`, etc., seen in `fake-gateway-transport.ts`) and
validates every generated fixture, replay cassette, and fuzz case against them.
On top of the fakes it provides deterministic Phase 180 release gates:
deployment smoke (`deployment-smoke.ts`), network impairment
(`network-impairment.ts`), security regression (`security-regression.ts`),
performance budgets (`performance-budgets.ts`), protocol fuzzing
(`protocol-fuzzing-harness.ts`), a record/replay sandbox
(`record-replay-sandbox.ts`), and the MVP-alpha release-gate evaluator
(`mvp-alpha-release-gate.ts`) with SLO, soak, demo-scenario, and
bridge-coexistence plans. Crucially, it is honest about its limits: non-local
deployment modes are labelled `live-hardware-required`, TURN fallback is an
explicit placeholder scenario, and the gates document that they prove the
contracts are complete and testable without claiming real hardware/cloud
evidence has been exercised.