Generic dual-spawn vitest globalSetup factory — spawns + bootstraps
*two* backends at once and provides both serialized handles, for any
cross-impl gate that needs both alive together. (The per-backend
create_cross_backend_global_setup derives one backend from the project
name; this brings up a pair.)
Its primary use is the schema- / action-manifest-parity gates (capture
each backend over a _testing_* introspection RPC and diff with
assert_schema_snapshots_equal / assert_action_manifests_equal) — which is
why the default provide_keys are parity_handle_*. The login-security gate
(global_setup_login_security.ts) reuses it with its own keys; any future
two-backend gate can too.
A consumer's dual-spawn global_setup.ts collapses to:
import {create_dual_spawn_global_setup} from
'@fuzdev/fuz_app/testing/cross_backend/create_dual_spawn_global_setup.ts';
import {deno_backend_config, rust_backend_config} from './my_backend_config.js';
import './cross_test_types.js'; // augments the two provide keys
export default create_dual_spawn_global_setup({
configs: {a: deno_backend_config, b: rust_backend_config},
});The .cross.test.ts injects both keys, rebuilds each with
reconstruct_bootstrapped_handle, and asserts. Run this project in a
later groupOrder than the single-backend projects (or with distinct
ports) — it reuses both configs' ports, so it must not run concurrently
with the per-backend projects.
2 declarations
testing/cross_backend/create_dual_spawn_global_setup.ts view source
({ configs, provide_keys, }: DualSpawnGlobalSetupOptions): (project: TestProject) => Promise<() => Promise<void>> import {create_dual_spawn_global_setup} from '@fuzdev/fuz_app/testing/cross_backend/create_dual_spawn_global_setup.js'; Build a vitest globalSetup default export that spawns both backends.
__0(project: TestProject) => Promise<() => Promise<void>> testing/cross_backend/create_dual_spawn_global_setup.ts view source
DualSpawnGlobalSetupOptions import type {DualSpawnGlobalSetupOptions} from '@fuzdev/fuz_app/testing/cross_backend/create_dual_spawn_global_setup.js'; configsThe two backend config factories to spawn. a is spawned first; on
its success b is spawned (with a torn down if b throws). Label
them in the consuming test (e.g. via assert_schema_snapshots_equal's labels).
type {readonly a: () => BackendConfig; readonly b: () => BackendConfig}
provide_keys?project.provide keys for the two serialized handles (read by
inject in the test). Default parity_handle_a / parity_handle_b
(the primary parity use); override for other dual-spawn gates. Augment
vitest's ProvidedContext for whichever keys you use.
type {readonly a: string; readonly b: string}