fix(tests): break the irtt-client/irtt-server dev-dependency cycle #115

2026-08-17T02:49:54Z

Lochnair commented

2026-08-17 02:49:54 +00:00

(Migrated from github.com)

Summary

While working through the crates.io publication step of #114, cargo publish deadlocked on irtt-client/irtt-server: they mutually dev-depend on each other for cross-crate integration tests, so neither can be the "first" of the pair to publish — each needs the other to already exist on the registry at the target version. This is normally invisible (path deps resolve fine inside the workspace), but blocks a first-ever publish, which is exactly irtt-server's situation.

Fixes it by introducing a dedicated irtt-integration-tests crate (publish = false, no library target) that owns tests whose actual subject is the interaction between two or more irtt-* production crates, per this rule:

crate-local behavior          -> crate's own tests/
cross-crate/system behavior   -> irtt-integration-tests

Moved every test file that imports both irtt_client and irtt_server (client-side support harness: hmac, large_packets, protocol_options, fill_negotiation; server-side real-socket tests: async_client, negotiation_policy, fill_wire_bytes, traffic_class, wildcard_source) into irtt-integration-tests/tests/.
Left irtt-server/tests/server_set.rs in place — it only uses irtt_proto as test machinery to drive irtt-server directly, a normal one-directional test dependency, not a peer relationship.
Dropped irtt-server's dev-dependency on irtt-client entirely, which fully breaks the cycle from that side.
Kept irtt-client's dev-dependency on irtt-server: a handful of white-box unit tests in src/async_client/tests.rs assert on private AsyncClient internals (socket, remote, test_hooks) while also needing a real in-tree server for blocking/async equivalence checks, so they can't move to an external crate without losing that access. Duplicated the small InTreeServer helper locally for this, matching the existing precedent of irtt-cli's own tests/support/in_tree_server.rs.

Net effect: irtt-client -> irtt-server is now a one-directional dev-dependency, so irtt-server can publish first with no dev-dependency to block it, and irtt-client can publish afterward.

No production code changed — this is test organization plus two Cargo.toml dependency edits.

Test plan

cargo fmt --all -- --check
cargo check --workspace --all-targets --all-features
cargo test --workspace --all-features — all green, 0 failures, including every moved test file (verified irtt-integration-tests' 9 test binaries all ran and passed)
cargo clippy --workspace --all-targets --all-features -- -D warnings
cargo publish --dry-run --allow-dirty -p irtt-server — now packages and fully verifies (previously failed at packaging because it needed irtt-client on the registry)
dist plan — confirms irtt-integration-tests isn't picked up as a dist-able app (no bin target), unaffected by the change

## Summary While working through the crates.io publication step of #114, `cargo publish` deadlocked on `irtt-client`/`irtt-server`: they mutually `dev-depend` on each other for cross-crate integration tests, so neither can be the "first" of the pair to publish — each needs the other to already exist on the registry at the target version. This is normally invisible (path deps resolve fine inside the workspace), but blocks a first-ever publish, which is exactly `irtt-server`'s situation. Fixes it by introducing a dedicated `irtt-integration-tests` crate (`publish = false`, no library target) that owns tests whose actual subject is the interaction between two or more `irtt-*` production crates, per this rule: ``` crate-local behavior -> crate's own tests/ cross-crate/system behavior -> irtt-integration-tests ``` - Moved every test file that imports both `irtt_client` and `irtt_server` (client-side support harness: `hmac`, `large_packets`, `protocol_options`, `fill_negotiation`; server-side real-socket tests: `async_client`, `negotiation_policy`, `fill_wire_bytes`, `traffic_class`, `wildcard_source`) into `irtt-integration-tests/tests/`. - Left `irtt-server/tests/server_set.rs` in place — it only uses `irtt_proto` as test machinery to drive `irtt-server` directly, a normal one-directional test dependency, not a peer relationship. - Dropped `irtt-server`'s dev-dependency on `irtt-client` entirely, which fully breaks the cycle from that side. - Kept `irtt-client`'s dev-dependency on `irtt-server`: a handful of white-box unit tests in `src/async_client/tests.rs` assert on private `AsyncClient` internals (`socket`, `remote`, `test_hooks`) while also needing a real in-tree server for blocking/async equivalence checks, so they can't move to an external crate without losing that access. Duplicated the small `InTreeServer` helper locally for this, matching the existing precedent of `irtt-cli`'s own `tests/support/in_tree_server.rs`. Net effect: `irtt-client -> irtt-server` is now a one-directional dev-dependency, so `irtt-server` can publish first with no dev-dependency to block it, and `irtt-client` can publish afterward. No production code changed — this is test organization plus two `Cargo.toml` dependency edits. ## Test plan - [x] `cargo fmt --all -- --check` - [x] `cargo check --workspace --all-targets --all-features` - [x] `cargo test --workspace --all-features` — all green, 0 failures, including every moved test file (verified `irtt-integration-tests`' 9 test binaries all ran and passed) - [x] `cargo clippy --workspace --all-targets --all-features -- -D warnings` - [x] `cargo publish --dry-run --allow-dirty -p irtt-server` — now packages **and fully verifies** (previously failed at packaging because it needed `irtt-client` on the registry) - [x] `dist plan` — confirms `irtt-integration-tests` isn't picked up as a dist-able app (no bin target), unaffected by the change

chatgpt-codex-connector[bot] commented

2026-08-17 02:50:00 +00:00

(Migrated from github.com)

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, you can upgrade your account or add credits to your account and enable them for code reviews in your settings.

You have reached your Codex usage limits for code reviews. You can see your limits in the [Codex usage dashboard](https://chatgpt.com/codex/cloud/settings/usage). To continue using code reviews, you can upgrade your account or add credits to your account and enable them for code reviews in your [settings](https://chatgpt.com/codex/cloud/settings/code-review).

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: Lochnair-Labs/irtt-rs#115