Xila

Appearance

Testing ​

The testing crate assembles a host integration runtime so tests can run against near-real Core wiring.

Role ​

  • Provides one high-level initializer that wires task/users/time, storage, optional graphics, optional networking, and standard streams.
  • Reduces per-test boilerplate by mounting known-good baseline devices and hierarchy.

Boundaries ​

  • In scope: integration-runtime bootstrap for tests.
  • Out of scope: unit-test micro scaffolding and production startup orchestration.

Internal structure ​

  • lib.rs exposes initialize(graphics_enabled, network_enabled) -> executable::Standard<'static>; the result carries an ExecutableContext with the assembled managers.
  • Setup logic is sequential and explicit: logging, managers, VFS root, device mounts, optional subsystems, seed user/account.

Runtime interaction ​

  1. Uses the task test-harness manager and constructs users/time managers; registers the logger.
  2. Optionally starts graphics manager and host window runner tasks.
  3. Creates memory-backed LittleFS and initializes VFS + default hierarchy.
  4. Mounts standard devices (/devices/random, /devices/hasher, stdio, time, null).
  5. Optionally mounts/configures a tuntap network interface and applies IP/routes/DNS.
  6. Seeds administrator group/user and environment variables (Paths, Host).
  7. Builds an ExecutableContext and returns opened Standard streams carrying those references for test/executable launch.

Dependency model ​

  • Depends on broad Core surface: file_system, little_fs, authentication, executable, network, graphics, task/users/time/log, plus host drivers.

Failure semantics ​

  • Initialization is intentionally strict and uses unwrap/expect in many places to fail fast in test setup.
  • Optional branches still fail the initializer if enabled and setup cannot complete.

Extension points ​

  • Additional device mounts can be added to the bootstrap sequence for new integration domains.
  • Feature toggles can extend the initializer signature if more optional subsystems are needed.

Contract vs implementation ​

  • Contract: one async initializer returning ready-to-use Standard for executing test binaries/workflows.
  • Current implementation: host-first initialization with memory-backed LittleFS, optional window/tuntap integration, and seeded administrator account.

Limitations and trade-offs ​

  • Fast-fail setup simplifies test diagnosis but is less granular than layered setup APIs.
  • Integration realism increases coverage while making initialization heavier than unit-test stubs.

Entry point and required environment ​

testing::initialize(graphics_enabled, network_enabled).await returns executable::Standard<'static> carrying a populated ExecutableContext. It is an integration test fixture: it leaks boxed runtime managers into 'static storage, installs the global logger and invokes the Task test-harness manager. Consequently it is not intended to construct multiple independent production OS instances in one process.

rust
let mut standard = testing::initialize(false, false).await;
let task = standard.context.task_manager.get_current_task_identifier().await;
let vfs = standard.context.virtual_file_system;
assert!(vfs.get_statistics(&"/devices/null").await.is_ok());

This is an integration-harness example. A suitable test executor/spawner, global allocator and host driver environment must already be configured; the initializer does not install all of them in an otherwise empty process.

Fixture composition and feature-dependent behavior ​

The fixture creates a 512 KiB in-memory block device with MemoryDevice::<512>::new_static, formats LittleFS with a cache size of 256 bytes, mounts it as the VFS root and creates the default hierarchy. It exposes random/time/hash/null/console/CPU-information devices. The seeded administrator has group and user ID 1000 and is created with an empty password; this is test-only behavior, not a production default.

  • When graphics is enabled, it starts an 800 × 600 native window, creates the Graphics manager and spawns both LVGL and screen runner tasks.
  • When networking is enabled, it uses the platform TUN/TAP driver, configures a tunnel interface and mounts HTTP/HTTPS client devices. This requires host networking support and permissions.
  • The returned Standard streams expose the same live devices and managers to launched executables.

The function signature accepts graphics_enabled even when the crate's graphics Cargo feature is disabled; check the configured feature set before assuming graphics types and setup exist. The fixture intentionally uses unwrap/expect on setup failures so tests fail immediately rather than returning a recoverable configuration error.

Isolation and cleanup limitations ​

Managers and devices are leaked for lifetime convenience. Global logger state and the Task test harness can affect later tests in the same process. Prefer separate test processes for scenarios that mutate global runtime state, and use narrower mocks (GpioMock, a memory device, etc.) for small deterministic unit tests.

Source and API references ​

References ​