Testing

Compilation validates macro and extractor signatures. A real socket test checks Origin/subprotocol, the wire envelope, ACK correlation, and shutdown together. These provide different kinds of evidence.

Add a test to the first application#

Keep the first application's code as src/main.rs. Add the following dev-dependencies to the manifest:

[dev-dependencies]
futures-util = "0.3"
serde_json = "1"
tokio = { version = "1", features = ["full"] }
tokio-util = "0.7"
tokio-tungstenite = "0.23.1"

Download the test file and save it as tests/first_application.rs. The test includes the controller in its own test binary with #[path = "../src/main.rs"]; this setup is for the first application's single-file layout.

cargo test --test first_application

The test allocates an available loopback port, starts the app with a caller token, and connects with the correct Origin and subprotocol. It verifies the caller event, matching ACK, and missing ACK ID error in order, then checks that the active connection count is zero after shutdown.

Measure actual behavior#

Bound socket reads and shutdown waits with timeouts. Assert msg_type, route, ACK ID, and error code rather than merely checking that a message arrived. A race is possible between port selection and bind, so retries remain bounded and apply only to I/O during connection startup; they must not hide policy failures.

The test file's main assertions:

assert_eq!(output["msg_type"], expected_type);
if expected_type == "ack" {
    assert_eq!(output["ack_id"], "request-1");
}
if expected_type == "error" {
    assert_eq!(output["data"]["code"], "WS_MISSING_ACK_AUTHORITY");
}

This snippet is part of the complete downloadable test. The test does not pass merely by mocking framework APIs; it reads actual envelopes from a loopback WebSocket connection.

Application test plan#

Exercise your real database/Redis/auth integrations in your test environment. A compile-pass example alone does not prove a provider's correctness or transaction behavior.

Validation at the reviewed revision#

Historical record — 14 September 2026, fabed7e8b9ad140528e1254e91c023a7059b927d: During the earlier source review, 534 library tests passed and one Docker/Autobahn test remained ignored. Five tests passed in selected integration targets, with two Docker OTLP tests ignored. Macro contracts were verified in serial runs through 18 compile-fail and four compile-pass fixtures. The first application's real socket test also passed.

These counts record the earlier review; they are not compilation or runtime results for the new registry examples. The published release requires Rust 1.96.1. Live PostgreSQL, MongoDB, and Redis data operations and Docker scenarios are validated separately from compilation of site examples. The partial-frame UTF-8 fail-fast boundary is explained in the reference. Rerun relevant tests when examples or framework code change.

Validate the published packages#

18 September 2026 — crates.io 0.1.0, Rust 1.96.1: All 33 downloadable Rust examples (15 HTTP, 18 WebSocket) and three separate factory contracts passed compilation checks in isolated profiles using registry dependencies: 36/36. No framework path, Git, or [patch] override was used. Turkish examples were compiled; executable-code parity of English files is checked separately by site tests.

Four WebSocket runtime tests also passed on the same date:

These results do not mean live PostgreSQL/MongoDB/Redis operations or an external WebSocket client connection were tested. The manual-client test checks the profile's DI startup behavior; the new background test checks host ownership and shutdown ordering. The 14 September framework test counts above are separate from these new results.

For lilyrs 0.1.0, validate startup, DI, PostgreSQL, MongoDB, Redis, direct-client, gateway, and worker examples under their own dependency profiles. Use registry versions in manifests; adding a framework path, Git, or [patch] override does not prove the published package compiles. Cargo.lock and cargo tree -e features show the packages and features resolved.

Compile single and factory alternatives in separate fixtures/workspaces; --all-features is invalid for this model. Also verify that server build under the direct client's websocket-client-di profile does not require [websocket_client], and that BaseGateway's direct dependencies are complete. Test actual startup/cancellation/join behavior as well as compilation for the new worker example.

From the documentation repository root, you can run the first application's registry compilation and downloadable socket test separately:

python3 scripts/check-rust-examples.py --profile websocket-first-app
python3 scripts/check-rust-examples.py --profile websocket-first-application-test --mode smoke

The script uses Rust 1.96.1 and isolated registry manifests. Running without a profile selection checks all documentation Rust examples and factory contracts; --mode smoke runs selected HTTP/WS runtime checks. Assess compilation, socket, and external-system test coverage separately in the output.

The framework repository's release qualification results are evidence with their own release-candidate date and scope. Do not treat them as rerun tests of the updated site examples. Live database/backplane operations, failure injection, and sustained load tests require a separate integration environment.