5.7 KiB
RVBox implementation test workflow
All Go, protobuf, and harness work runs in the pinned toolchain container. No host Go installation is used.
Run the normal pre-commit gate with:
make verify
Run focused unit tests with:
scripts/test-unit --package ./internal/domain --run UUIDv7 --race
The integration harness provides the Phase 0 sample suite, the incremental
Phase 2 store suite, and the incremental Phase 3 server-session suite.
The resumable E2E harness adds smoke, script, recovery, and all
scenarios. Each run writes its manifest and run ID before starting work.
The storage suite uses a real temporary SQLite database in WAL mode and a real
segment/audit filesystem. The session suite uses a real HTTP/WebSocket listener,
binary protobuf frames, SQLite fencing, and the race detector; neither mocks its
respective durability or wire boundary:
scripts/test-env doctor
scripts/test-integration --suite sample --run-id my-sample
scripts/test-env status --run-id my-sample
scripts/test-env collect --run-id my-sample
scripts/test-env reset --run-id my-sample
scripts/test-env reuse --run-id my-sample
scripts/test-integration --suite sample --run-id my-sample --resume
scripts/test-env reset --run-id my-sample
scripts/test-env purge --run-id my-sample
scripts/test-integration --suite store --run-id store-smoke
scripts/test-env logs --run-id store-smoke
scripts/test-env collect --run-id store-smoke
scripts/test-env reset --run-id store-smoke
scripts/test-env purge --run-id store-smoke
scripts/test-integration --suite server-session --run-id session-smoke
scripts/test-env logs --run-id session-smoke
scripts/test-env collect --run-id session-smoke
scripts/test-env reset --run-id session-smoke
scripts/test-env purge --run-id session-smoke
scripts/test-e2e --scenario smoke --run-id e2e-smoke
scripts/test-env status --run-id e2e-smoke
scripts/test-env recover --run-id e2e-smoke
scripts/test-e2e --scenario smoke --run-id e2e-smoke --resume
scripts/test-env reset --run-id e2e-smoke
scripts/test-env purge --run-id e2e-smoke
The client runtime unit lane also exercises a real child process through the
portable supervisor adapter. internal/client/agent/executor_test.go verifies
that command text is accepted once, output is journaled, lifecycle/terminal
events are durable, and a script cannot launch before its contiguous upload is
committed. The Windows build uses the same executor contract with the
platform-native adapter: a verified token is selected, the child is created
suspended, assigned to a kill-on-close Job, and held behind an authenticated
per-command launcher pipe. The daemon records launch_prepared, then the
durable launch_authorized transition sends the launcher's release frame; the
launcher resumes the shell only after that acknowledgement. The durable
launch_phase barrier is recovered as interrupted after a daemon restart, so
an uncertain release is never redispatched.
The Windows artifact is linked with the GUI subsystem (-H=windowsgui) so
service, launcher, and tray startup do not flash a console. Human-facing modes
still attach to a parent console explicitly when one exists.
Suite output is capped at 1 MiB and stored as artifacts/suite.log. A failed
run remains inspectable and can be moved back to ready with recover, then
resumed with the same run ID and deterministic shuffle seed. Test-run cleanup
never removes the shared Go module or build-cache volumes.
Each run owns only .test-runs/<run-id> and resources explicitly recorded in
that run's versioned manifest. The journal is append-only and fsynced. purge
validates the run ID and manifest identity, refuses symlink targets or manifests
that still list runtime resources, and then removes only that exact run. Purged
artifacts are not recoverable. Dependency cache volumes are never part of run
cleanup.
test/coverage.toml is the incremental requirement-to-test inventory. The
make verify lint stage checks unique stable IDs and verifies every implemented
test reference against source. A resettable Windows smoke VM is now available.
The authoritative fixture record is
testing-vm.md: it lists the VM/host UUIDs, Windows build,
hardware and device profile, NAT and VRDE endpoints, snapshot UUIDs,
credential-file contract, and the required reset sequence. At the last check
the VM was powered off with baseline-disk-first selected. The guest address
10.0.2.15 is DHCP state only; use SSH plus VirtualBox Guest Control rather
than treating it as a stable endpoint. VRDE is enabled at
192.168.50.162:3389 for diagnostics, while native Windows RDP is disabled in
the baseline.
The exact headless VirtualBox/Guest Control adapter is
scripts/windows/test-host.ps1; it takes the VM name, baseline snapshot, and
guest identity/password-file only from host environment variables, acquires an
exclusive lease, and never writes secrets to the repository. Set
RVBOX_WINDOWS_GUEST_PASSWORD_FILE to a mode-600 file outside the repository;
the adapter passes it with VirtualBox --passwordfile and never accepts an
inline password. Use Prepare, Run,
Collect, Stop, and Reset in that order for a native run. The VM is the
minimum smoke lane, so deferred native multi-session/ambiguous-session, Server
Core, and older-build entries remain explicitly blocked until their own
fixtures exist. A previous Windows 10 fixture probe found that VirtualBox Guest
Control 7.2.16 rejects the GUI-subsystem rvbox.exe as a directly runnable
guest executable; wrapping it through cmd.exe exited the RVBox process but
left the Guest Control wrapper waiting. This remains an adapter completion-path
limitation: native runtime coverage needs a service-driven or
console-compatible guest runner. Wine or a protocol stub is not treated as
equivalent coverage.