This documentation is part of the "Projects with Books" initiative at zenOSmosis.
The source code for this project is available on GitHub.
Testing Infrastructure
Loading…
Testing Infrastructure
Relevant source files
The Muxio project employs a multi-layered testing strategy designed to validate the reliability of the binary framing protocol, the RPC multiplexing engine, and the various transport implementations (Tokio, IPC, and WASM). The infrastructure is split between unit tests within the core crate and a specialized integration testing harness used to bypass circular dependency issues during the publishing process.
Testing Strategy Overview
The testing architecture is divided into three primary tiers:
- Core Unit & Integration Tests: Located in the
muxio-corecrate, these validate the fundamental logic of theFrameandRPClayers using in-memory buffers. - Extension Integration Tests : Located in the
muxio-ext-testcrate, these perform end-to-end validation of network transports (WebSocket, IPC, MPSC) and complex scenarios like concurrent calls and WASM bridging. - Continuous Integration : A GitHub Actions pipeline that ensures cross-platform compatibility, feature-flag consistency, and code coverage.
Workspace Test Distribution
| Test Category | Location | Primary Focus |
|---|---|---|
| Core Unit Tests | muxio-core/src/ | Internal logic of FrameCodec, RpcDispatcher, and RpcSession. |
| Core Integration Tests | muxio-core/tests/ | Interaction between Frame and RPC layers without external networking. |
| Transport Integration | extensions/muxio-ext-test/tests/ | RpcServer and RpcClient interaction over real sockets and IPC. |
| CI Configuration | .github/workflows/rust-tests.yml | Multi-OS testing, cargo-llvm-cov, and workspace-wide validation. |
Sources: .github/workflows/rust-tests.yml:1-30 extensions/muxio-ext-test/Cargo.toml:1-32
Core Library Tests
The core library tests focus on the state machines governing stream lifecycles and multiplexing. These tests ensure that the FrameMuxStreamDecoder correctly reassembles interleaved frames and that the RpcDispatcher maintains request-response correlation under high concurrency.
For details on specific test suites like rpc_dispatcher_tests and frame_stream_tests, see Core Library Tests.
Integration Tests & muxio-ext-test Harness
A unique challenge in the Muxio workspace is the circular dependency between transport crates and the test utilities that require them. To resolve this for crate publishing, all integration tests for extension crates reside in the muxio-ext-test crate. This crate is a utility package that exists solely to house dependencies on all other workspace members, including muxio-tokio-rpc-server, muxio-tokio-rpc-client, muxio-wasm-rpc-client, and the IPC transports extensions/muxio-ext-test/Cargo.toml:14-32
Automated Test Discovery
The muxio-ext-test crate allows developers to validate complex interactions across crates—such as the muxio-tokio-mpsc-adapter or muxio-tokio-rpc-ipc-server—without cluttering the individual crates’ dev-dependencies.
Code Entity Mapping: Test Environment
The following diagram illustrates how the muxio-ext-test crate acts as a bridge to test the various transport implementations.
Integration Test Architecture
graph TD
subgraph "muxio-ext-test [Harness]"
TT["TestTransport Trait"]
TM["Test Macros"]
end
subgraph "Transport Under Test"
WS["muxio-tokio-rpc-server / client"]
IPC["muxio-tokio-rpc-ipc-server / client"]
WASM["muxio-wasm-rpc-client"]
end
subgraph "Service Layer"
SD["example-muxio-rpc-service-definition"]
EP["muxio-rpc-service-endpoint"]
end
TT --> WS
TT --> IPC
TT --> WASM
WS & IPC &
WASM --> SD
WS &
IPC --> EP
Sources: extensions/muxio-ext-test/Cargo.toml:14-32 extensions/muxio-ext-test/README.md:1-14
For details on transport-specific tests and the proxy error propagation scenario, see Integration Tests & muxio-ext-test Harness.
Continuous Integration (CI)
The project utilizes GitHub Actions to maintain code quality across different environments. The rust-tests.yml workflow is configured to run on every push to main and for all pull requests .github/workflows/rust-tests.yml:6-10
CI Execution Flow
Sources: .github/workflows/rust-tests.yml:19-29 .github/workflows/rust-tests.yml:77-78 .github/workflows/rust-tests.yml:104-123
The CI pipeline ensures that the workspace is tested with --all-features to validate the various feature flag combinations, such as the tokio_support feature in the endpoint crate .github/workflows/rust-tests.yml78 It also generates coverage reports using cargo-llvm-cov to track testing depth across the core and extension modules .github/workflows/rust-tests.yml:167-169
Error Validation
Testing infrastructure also includes explicit validation of error types defined in the core. This includes FrameEncodeError and FrameDecodeError to ensure that the system handles corrupt data or protocol violations gracefully. These tests are critical for the FrameStreamEncoder and FrameMuxStreamDecoder components that form the backbone of the transport layer.
Sources: .github/workflows/rust-tests.yml:77-87 extensions/muxio-ext-test/Cargo.toml:20-23