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 catalog (3)#
The 3 tracked Nx projects in testing, each a code-linked entity node — package, type, source path, declared targets, and its internal dependency graph (depends-on / used-by, resolved from the package manifests, §6/§8), read from the project graph. Grouped by architectural layer; walk the dependency links to travel the system. 2 of these carry an authored deep-dive (what / why / how it fits); the rest are generated scaffolds awaiting one.
test-infra (3)#
Bellona remote-control mock harness and protocol fixture utilities
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.
Held-out V1-V9 prompt-injection portfolio evaluations
Testing infrastructure and configuration for Oshun Platform
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.