Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

GitHub

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:

  1. Core Unit & Integration Tests: Located in the muxio-core crate, these validate the fundamental logic of the Frame and RPC layers using in-memory buffers.
  2. Extension Integration Tests : Located in the muxio-ext-test crate, these perform end-to-end validation of network transports (WebSocket, IPC, MPSC) and complex scenarios like concurrent calls and WASM bridging.
  3. Continuous Integration : A GitHub Actions pipeline that ensures cross-platform compatibility, feature-flag consistency, and code coverage.

Workspace Test Distribution

Test CategoryLocationPrimary Focus
Core Unit Testsmuxio-core/src/Internal logic of FrameCodec, RpcDispatcher, and RpcSession.
Core Integration Testsmuxio-core/tests/Interaction between Frame and RPC layers without external networking.
Transport Integrationextensions/muxio-ext-test/tests/RpcServer and RpcClient interaction over real sockets and IPC.
CI Configuration.github/workflows/rust-tests.ymlMulti-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