Extend wireframe_testing with codec-aware drivers and app codec#484
Extend wireframe_testing with codec-aware drivers and app codec#484
Conversation
…testing - Introduce payload-level and frame-level codec-aware driver functions that handle encoding and decoding transparently for any FrameCodec. - Add generic encode/decode helper functions for FrameCodec implementations. - Provide a new codec() accessor on WireframeApp for convenient codec access. - Implement comprehensive unit and BDD tests for the new codec-aware testing APIs. - Document the new testing capabilities in users-guide, update ADR and roadmap accordingly. Co-authored-by: devboxerhub[bot] <devboxerhub[bot]@users.noreply.github.com>
WalkthroughExtend wireframe_testing with codec-aware helpers and drivers plus a public Changes
Sequence DiagramsequenceDiagram
participant Test as "Test (caller)"
participant Encoder as "Encoder (codec)"
participant App as "WireframeApp"
participant Decoder as "Decoder (codec)"
participant Output as "Payload extractor"
Test->>Encoder: encode_payloads_with_codec(payloads)
activate Encoder
Encoder->>Encoder: wrap_payload -> frames
Encoder->>Encoder: encode frames -> bytes
Encoder-->>Test: encoded_bytes
deactivate Encoder
Test->>App: drive_with_codec_payloads(app, codec, payloads)
activate App
App->>App: write encoded_bytes to duplex
App->>App: process handlers / echo
App-->>Test: raw_output_bytes
deactivate App
Test->>Decoder: decode_frames_with_codec(codec, raw_output_bytes)
activate Decoder
Decoder->>Decoder: feed bytes -> collect frames
Decoder-->>Test: Vec<Frame>
deactivate Decoder
Test->>Output: extract_payloads(frames)
activate Output
Output->>Output: extract payload from each frame
Output-->>Test: Vec<Vec<u8>>
deactivate Output
Test->>Test: assert payloads match expectations
Estimated code review effort🎯 4 (Complex) | ⏱️ ~40 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches
🧪 Generate unit tests (beta)
Comment |
Reviewer's GuideImplements codec-aware testing support by adding a public codec accessor on WireframeApp, new codec-based encode/decode helpers and in-memory drivers in wireframe_testing, plus integration/BDD tests and documentation/roadmap updates to validate and describe the new workflow. Sequence diagram for drive_with_codec_payloads_with_capacity_mut flowsequenceDiagram
actor TestAuthor
participant Driver as CodecDriveHelpers
participant CodecExt as CodecExtHelpers
participant Drive as DriveInternal
participant App as WireframeApp
TestAuthor->>Driver: drive_with_codec_payloads_with_capacity_mut(app_mut, codec_ref, payloads, capacity)
activate Driver
Driver->>CodecExt: encode_payloads_with_codec(codec_ref, payloads)
activate CodecExt
CodecExt-->>Driver: encoded_frames
deactivate CodecExt
Driver->>Drive: drive_internal(server_fn, encoded_frames, capacity)
activate Drive
Note right of Drive: server_fn = |server| async { app.handle_connection(server).await }
Drive->>App: handle_connection(duplex_server)
activate App
App-->>Drive: writes_response_bytes
deactivate App
Drive-->>Driver: raw_bytes
deactivate Drive
Driver->>CodecExt: decode_frames_with_codec(codec_ref, raw_bytes)
activate CodecExt
CodecExt-->>Driver: frames
deactivate CodecExt
Driver->>CodecExt: extract_payloads(frames)
activate CodecExt
CodecExt-->>Driver: response_payloads
deactivate CodecExt
Driver-->>TestAuthor: response_payloads
deactivate Driver
Class diagram for codec-aware testing helpers and WireframeApp accessorclassDiagram
class WireframeApp~S,C,E,F~ {
+codec() &F
+with_codec(codec F) WireframeApp~S,C,E,F~
+handle_connection(server DuplexStream) async
}
class FrameCodec~F~ {
<<interface>>
+decoder() Decoder
+encoder() Encoder
+frame_payload(frame F::Frame) Bytes
+wrap_payload(payload Bytes) F::Frame
+correlation_id(frame F::Frame) CorrelationId
+max_frame_length() usize
F::Frame
F::Decoder
F::Encoder
}
class TestSerializer {
<<trait>>
+serialize(packet Packet) Vec~u8~
+deserialize(bytes Vec~u8~) Packet
}
class Packet {
<<trait>>
}
class CodecExtHelpers {
<<static>>
+encode_payloads_with_codec(codec F, payloads Vec~Vec~u8~~) Result~Vec~Vec~u8~~,io::Error~
+decode_frames_with_codec(codec F, bytes Vec~u8~) Result~Vec~F::Frame~,io::Error~
+extract_payloads(frames F::Frame[]) Vec~Vec~u8~~
}
class CodecDriveHelpers {
<<static>>
+drive_with_codec_payloads(app WireframeApp~S,C,E,F~, codec F, payloads Vec~Vec~u8~~) async Result~Vec~Vec~u8~~,io::Error~
+drive_with_codec_payloads_with_capacity(app WireframeApp~S,C,E,F~, codec F, payloads Vec~Vec~u8~~, capacity usize) async Result~Vec~Vec~u8~~,io::Error~
+drive_with_codec_payloads_mut(app WireframeApp~S,C,E,F~, codec F, payloads Vec~Vec~u8~~) async Result~Vec~Vec~u8~~,io::Error~
+drive_with_codec_payloads_with_capacity_mut(app WireframeApp~S,C,E,F~, codec F, payloads Vec~Vec~u8~~, capacity usize) async Result~Vec~Vec~u8~~,io::Error~
+drive_with_codec_frames(app WireframeApp~S,C,E,F~, codec F, payloads Vec~Vec~u8~~) async Result~Vec~F::Frame~,io::Error~
+drive_with_codec_frames_with_capacity(app WireframeApp~S,C,E,F~, codec F, payloads Vec~Vec~u8~~, capacity usize) async Result~Vec~F::Frame~,io::Error~
}
class DriveInternal {
<<static>>
+drive_internal(server_fn FnOnce, frames Vec~Vec~u8~~, capacity usize) async Result~Vec~u8~,io::Error~
}
WireframeApp ..> FrameCodec : uses F
WireframeApp ..> TestSerializer : uses S
WireframeApp ..> Packet : uses E
CodecExtHelpers ..> FrameCodec : generic F
CodecDriveHelpers ..> WireframeApp : drives
CodecDriveHelpers ..> FrameCodec : encodes_decodes
CodecDriveHelpers ..> CodecExtHelpers : calls
CodecDriveHelpers ..> DriveInternal : calls
TestSerializer <|.. ConcreteSerializer
FrameCodec <|.. HotlineFrameCodec
class ConcreteSerializer {
}
class HotlineFrameCodec {
}
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
There was a problem hiding this comment.
Hey - I've found 5 issues, and left some high level feedback:
- The various owned/mut and capacity/non-capacity codec driver variants in
codec_driverepeat the same encode → drive_internal → decode pipeline; consider factoring that into an internal helper to minimise duplication and the risk of behavioural drift between variants. - In the new tests and helpers you use
io::Error::other(...); if the project’s MSRV is below the stabilisation ofError::other, you may want to replace these withio::Error::new(io::ErrorKind::Other, ...)to avoid compatibility issues.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- The various owned/mut and capacity/non-capacity codec driver variants in `codec_drive` repeat the same encode → drive_internal → decode pipeline; consider factoring that into an internal helper to minimise duplication and the risk of behavioural drift between variants.
- In the new tests and helpers you use `io::Error::other(...)`; if the project’s MSRV is below the stabilisation of `Error::other`, you may want to replace these with `io::Error::new(io::ErrorKind::Other, ...)` to avoid compatibility issues.
## Individual Comments
### Comment 1
<location path="docs/execplans/9-7-1-codec-aware-wireframe-testing.md" line_range="442-443" />
<code_context>
+
+Quality criteria (what "done" means):
+
+- Tests: `make test` passes, including the new rstest unit tests in
+ `wireframe_testing/src/helpers/tests/codec_drive_tests.rs` and the new
+ rstest-bdd scenarios in `tests/scenarios/codec_test_harness_scenarios.rs`.
+- Lint: `make lint` passes (Clippy with `-D warnings` on all targets).
</code_context>
<issue_to_address>
**issue (testing):** Update the referenced test path to match the final integration-test location.
This still points to `wireframe_testing/src/helpers/tests/codec_drive_tests.rs`, but earlier you noted the tests were moved to `tests/codec_test_harness.rs` as integration tests. Please update this bullet to reference the current test file(s) so the quality criteria match the actual layout.
</issue_to_address>
### Comment 2
<location path="wireframe_testing/src/helpers/codec_drive.rs" line_range="153" />
<code_context>
+where
+ S: TestSerializer, C: Send + 'static, E: Packet, F: FrameCodec;
+
+pub async fn drive_with_codec_payloads_with_capacity_mut<S, C, E, F>(
+ app: &mut WireframeApp<S, C, E, F>,
+ codec: &F,
</code_context>
<issue_to_address>
**issue (complexity):** Consider extracting a shared internal helper for the common encode/drive/decode pipeline so the owned and mutable helpers both delegate to a single frames-based implementation.
You can reduce duplication and make the API surface easier to reason about by extracting a single internal “frames impl” helper and expressing both the owned and `&mut` payload helpers in terms of it.
For example, factor out the common encode/drive/decode pipeline:
```rust
use std::future::Future;
async fn drive_frames_impl<S, C, E, F, H, Fut>(
handler: H,
codec: &F,
payloads: Vec<Vec<u8>>,
capacity: usize,
) -> io::Result<Vec<F::Frame>>
where
S: TestSerializer,
C: Send + 'static,
E: Packet,
F: FrameCodec,
H: FnOnce(wireframe::app::ServerSide) -> Fut,
Fut: Future<Output = io::Result<()>>,
{
let encoded = encode_payloads_with_codec(codec, payloads)?;
let raw = drive_internal(handler, encoded, capacity).await?;
decode_frames_with_codec(codec, raw)
}
```
Then use this in the existing frame-level API:
```rust
pub async fn drive_with_codec_frames_with_capacity<S, C, E, F>(
app: WireframeApp<S, C, E, F>,
codec: &F,
payloads: Vec<Vec<u8>>,
capacity: usize,
) -> io::Result<Vec<F::Frame>>
where
S: TestSerializer,
C: Send + 'static,
E: Packet,
F: FrameCodec,
{
drive_frames_impl(
|server| async move { app.handle_connection(server).await },
codec,
payloads,
capacity,
)
.await
}
```
And reuse the same primitive for the mutable payload helper instead of re-implementing the chain:
```rust
pub async fn drive_with_codec_payloads_with_capacity_mut<S, C, E, F>(
app: &mut WireframeApp<S, C, E, F>,
codec: &F,
payloads: Vec<Vec<u8>>,
capacity: usize,
) -> io::Result<Vec<Vec<u8>>>
where
S: TestSerializer,
C: Send + 'static,
E: Packet,
F: FrameCodec,
{
let frames = drive_frames_impl(
|server| async { app.handle_connection(server).await },
codec,
payloads,
capacity,
)
.await?;
Ok(extract_payloads::<F>(&frames))
}
```
With this in place:
- `drive_with_codec_frames`/`_with_capacity` are thin wrappers over `drive_frames_impl`.
- Both `drive_with_codec_payloads_with_capacity` and `drive_with_codec_payloads_with_capacity_mut` reuse the same encode/drive/decode primitive plus `extract_payloads`.
- The default-capacity variants stay as they are, just delegating to the corresponding `*_with_capacity` functions.
This keeps the existing public API and behavior but removes the asymmetric, duplicated encode/drive/decode logic and makes future changes to the pipeline (e.g., logging, metrics) localized to one helper.
</issue_to_address>
### Comment 3
<location path="wireframe_testing/src/helpers/codec_ext.rs" line_range="27" />
<code_context>
+/// use wireframe_testing::encode_payloads_with_codec;
+///
+/// let codec = HotlineFrameCodec::new(4096);
+/// let frames = encode_payloads_with_codec(&codec, vec![vec![1, 2, 3]]).unwrap();
+/// assert!(!frames.is_empty());
+/// ```
</code_context>
<issue_to_address>
**issue (review_instructions):** Example code uses `.unwrap()` where the guidelines require `.expect(...)`.
The coding guidelines prefer `.expect(...)` over `.unwrap()` so failures carry a helpful message. Please update this example to use `.expect("...")` instead of `.unwrap()`, e.g. `encode_payloads_with_codec(...).expect("encode_payloads_with_codec should succeed in this example")`.
<details>
<summary>Review instructions:</summary>
**Path patterns:** `**/*.rs`
**Instructions:**
Prefer `.expect()` over `.unwrap()`
</details>
</issue_to_address>
### Comment 4
<location path="wireframe_testing/src/helpers/codec_ext.rs" line_range="67" />
<code_context>
+/// use wireframe_testing::{decode_frames_with_codec, encode_payloads_with_codec};
+///
+/// let codec = HotlineFrameCodec::new(4096);
+/// let wire: Vec<u8> = encode_payloads_with_codec(&codec, vec![vec![42]])
+/// .unwrap()
+/// .into_iter()
</code_context>
<issue_to_address>
**issue (review_instructions):** The doc example below uses `.unwrap()` twice instead of the preferred `.expect(...)`.
In the example that follows, both the `encode_payloads_with_codec(...).unwrap()` and `decode_frames_with_codec(...).unwrap()` calls should use `.expect("...")` per the guidelines. This keeps example code consistent with the project’s error-handling conventions and provides clearer failure messages when the docs are run as tests.
<details>
<summary>Review instructions:</summary>
**Path patterns:** `**/*.rs`
**Instructions:**
Prefer `.expect()` over `.unwrap()`
</details>
</issue_to_address>
### Comment 5
<location path="docs/execplans/9-7-1-codec-aware-wireframe-testing.md" line_range="222" />
<code_context>
+delegate to it. It is `pub(super)`, accessible from sibling modules under
+`helpers/`.
+
+### BDD test pattern
+
+The project uses rstest-bdd v0.5.0. A BDD test domain consists of four files:
</code_context>
<issue_to_address>
**issue (review_instructions):** The heading introduces "BDD" without expanding the acronym, violating the requirement to define uncommon acronyms on first use.
Consider expanding BDD the first time it appears here, for example:
"### Behaviour-driven development (BDD) test pattern"
<details>
<summary>Review instructions:</summary>
**Path patterns:** `**/*.md`
**Instructions:**
Define uncommon acronyms on first use.
</details>
</issue_to_address>Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 027060722d
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
There was a problem hiding this comment.
Actionable comments posted: 6
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@docs/adr-004-pluggable-protocol-codecs.md`:
- Around line 238-240: There are duplicated "## Resolved decisions" headings;
remove the extra top-level heading and move the subsection "### Codec-aware test
harness drivers (9.7.1)" directly under the existing "## Resolved Decisions"
section so only a single canonical "## Resolved Decisions" heading remains and
the codec-aware subsection is nested under it.
In `@docs/execplans/9-7-1-codec-aware-wireframe-testing.md`:
- Around line 329-332: The docs reference the wrong test file and cargo command:
replace mentions of wireframe_testing/src/helpers/tests/codec_drive_tests.rs and
wiring via helpers/tests/mod.rs with the actual integration-test location
tests/codec_test_harness.rs, update the test summary lines to state the new
integration tests in tests/codec_test_harness.rs and
tests/scenarios/codec_test_harness_scenarios.rs, and change the verification
command from cargo test --package wireframe_testing to cargo test
codec_test_harness (also mirror this change for the other affected block around
lines 442-456); update any prose that implies unit tests in the helpers module
to explicitly say integration tests in tests/codec_test_harness.rs so the
validation steps match the final test location.
In `@docs/users-guide.md`:
- Around line 229-241: The fenced Rust example uses `?` and `.await` outside an
async fn which triggers doctest failures; update the code fence for the block
containing HotlineFrameCodec, WireframeApp, drive_with_codec_payloads and
drive_with_codec_frames to include the `no_run` attribute (i.e., mark it as
`rust,no_run`) so the snippet is skipped by doctests while keeping the example
intact.
- Around line 215-222: The fenced Rust example using WireframeApp and
HotlineFrameCodec uses the `?` operator and must be marked to avoid doctest
execution; change the code block marker from "```rust" to "```rust,no_run" for
the snippet that creates `WireframeApp::new()?`, `HotlineFrameCodec::new(4096)`,
and obtains `app.codec()` so that the example is not run by docs tests.
In `@wireframe_testing/src/helpers/codec_drive.rs`:
- Around line 165-174: Change the anonymous async block passed to drive_internal
to use "async move" so it captures the surrounding mutable reference
consistently: replace the current async { app.handle_connection(server).await }
with async move { app.handle_connection(server).await } in the call where
encode_payloads_with_codec, drive_internal, decode_frames_with_codec and
extract_payloads::<F> are used, mirroring the capture semantics used in
drive_with_codec_frames_with_capacity.
In `@wireframe_testing/src/helpers/codec_ext.rs`:
- Around line 75-90: The decode_frames_with_codec function currently only calls
decoder.decode in a loop and therefore ignores any trailing partial frame;
update it to call decoder.decode_eof(&mut buf) in a loop after the main decode
loop (mirroring tokio-util's FramedRead) and propagate decode errors the same
way (map_err -> io::Error::new with InvalidData); reference the
FrameCodec::decoder() created in decode_frames_with_codec and use
decoder.decode_eof to consume any final frames or surface an error for
incomplete data, and update the function docstring to state that decoding fails
on incomplete/truncated frames.
ℹ️ Review info
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
⛔ Files ignored due to path filters (1)
wireframe_testing/Cargo.lockis excluded by!**/*.lock
📒 Files selected for processing (17)
docs/adr-004-pluggable-protocol-codecs.mddocs/execplans/9-7-1-codec-aware-wireframe-testing.mddocs/roadmap.mddocs/users-guide.mdsrc/app/builder/codec.rstests/codec_test_harness.rstests/features/codec_test_harness.featuretests/fixtures/codec_test_harness.rstests/fixtures/mod.rstests/scenarios/codec_test_harness_scenarios.rstests/scenarios/mod.rstests/steps/codec_test_harness_steps.rstests/steps/mod.rswireframe_testing/src/helpers.rswireframe_testing/src/helpers/codec_drive.rswireframe_testing/src/helpers/codec_ext.rswireframe_testing/src/lib.rs
…me encoding/decoding Introduced new driver functions in `wireframe_testing` that accept any `FrameCodec` implementation and handle transparent frame encoding and decoding. These include payload-level and frame-level drivers that facilitate testing with raw payloads or codec-specific frame types, respectively. Added codec helper functions for encoding and decoding payloads and frames. Design choices ensure no new traits are introduced, codec is explicitly passed to avoid coupling, and a `codec()` accessor was added to `WireframeApp` for convenience. Updated documentation and tests to cover these new features, including integration tests outside the dev-dependency crate. This enhancement supports extensible and expressive protocol codec testing under roadmap item 9.7.1. Co-authored-by: devboxerhub[bot] <devboxerhub[bot]@users.noreply.github.com>
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (1)
docs/execplans/9-7-1-codec-aware-wireframe-testing.md (1)
38-40:⚠️ Potential issue | 🟡 MinorAlign early-stage wording with the final integration-test location.
Replace the remaining “unit tests in
wireframe_testing” phrasing with
integration-test wording to match the rest of this ExecPlan and the shipped
layout.As per coding guidelines, "Use markdown files within the `docs/` directory as a knowledge base and source of truth for project requirements, dependency choices, and architectural decisions."🧾 Proposed text correction
-Observable success: running `make test` passes, including new unit tests in -`wireframe_testing` and new rstest-bdd behavioural scenarios that exercise the +Observable success: running `make test` passes, including new integration tests +in `tests/codec_test_harness.rs` and new rstest-bdd behavioural scenarios that exercise the codec-aware drivers with `HotlineFrameCodec`. @@ -- [x] (2026-02-26) Stage D: add rstest unit tests for the new drivers. +- [x] (2026-02-26) Stage D: add integration tests for the new drivers.Also applies to: 96-97
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/execplans/9-7-1-codec-aware-wireframe-testing.md` around lines 38 - 40, Replace the phrasing "unit tests in `wireframe_testing`" with integration-test wording to match the ExecPlan and final layout: update occurrences of the exact phrase "unit tests in `wireframe_testing`" (and the duplicate instance later in the doc) to say "integration tests in `wireframe_testing`" or "integration tests in the wireframe_testing integration-test suite" so the description consistently refers to integration tests that live in the shipped test layout.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@docs/users-guide.md`:
- Around line 229-241: Import WireframeApp and replace the undefined
serialized_envelope with a concrete payload (e.g., a Vec<u8> like payload =
vec![0x01, 0x02, 0x03]); create the first app via
WireframeApp::new()?.with_codec(codec.clone()) and pass payload.clone() to
drive_with_codec_payloads(app, &codec, vec![payload.clone()]).await?; then
recreate the app (WireframeApp::new()?.with_codec(codec.clone())) before calling
drive_with_codec_frames(app, &codec, vec![payload]).await? so the app isn't
reused after being consumed. Ensure the use statement for WireframeApp is added
at the top.
---
Duplicate comments:
In `@docs/execplans/9-7-1-codec-aware-wireframe-testing.md`:
- Around line 38-40: Replace the phrasing "unit tests in `wireframe_testing`"
with integration-test wording to match the ExecPlan and final layout: update
occurrences of the exact phrase "unit tests in `wireframe_testing`" (and the
duplicate instance later in the doc) to say "integration tests in
`wireframe_testing`" or "integration tests in the wireframe_testing
integration-test suite" so the description consistently refers to integration
tests that live in the shipped test layout.
ℹ️ Review info
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (5)
docs/adr-004-pluggable-protocol-codecs.mddocs/execplans/9-7-1-codec-aware-wireframe-testing.mddocs/users-guide.mdwireframe_testing/src/helpers/codec_drive.rswireframe_testing/src/helpers/codec_ext.rs
|
@coderabbitai Have the following now been resolved? |
|
Tip For best results, initiate chat on the files or code changes. 🧩 Analysis chainI'll check the current state of the files to verify whether those review comments have been addressed. 🏁 Script executed: Length of output: 9094 Let me check the MSRV and look more closely at the BDD acronym situation: 🏁 Script executed: Length of output: 924 🏁 Script executed: Length of output: 2098 🏁 Script executed: Length of output: 683 🏁 Script executed: Length of output: 977
✅ All Issues AddressedComment 1: Test path in execplanRESOLVED — The quality criteria now correctly references Comment 2 & Overall Comment 1: Extract shared internal helperRESOLVED — The Comments 3 & 4:
|
Updated the example in the users-guide to correctly use drive_with_codec_payloads and drive_with_codec_frames functions with proper payload initialization and app instantiation order. This improves clarity and accuracy of the documentation for codec-aware driver functions. Co-authored-by: devboxerhub[bot] <devboxerhub[bot]@users.noreply.github.com>
Summary
Extend the codec test harness to support codec-aware in-memory drivers for WireframeApp. Adds a public codec accessor on WireframeApp, new codec-driven helpers, and a full integration/BDD test harness with payload- and frame-level driver capabilities. This completes the 9.7.1 objective in the roadmap and updates docs accordingly.
Changes
tests/scenarios/mod.rs and tests/steps/mod.rs updated accordingly.
Why
To enable testing against arbitrary FrameCodec implementations without boilerplate, improving test coverage for custom protocols and codecs. The new codec-aware drivers mirror the existing payload/frame testing patterns, while keeping API surface additive and non-breaking.
Design & Considerations
Testing plan
Impact
Notes for reviewers
◳ Generated by DevBoxer ◰
ℹ️ Tag @devboxerhub to ask questions and address PR feedback
📎 Task: https://www.devboxer.com/task/dadb1221-2dd3-40ec-a5f8-09ff33b2a503
Summary by Sourcery
Add codec-aware testing support and documentation updates for WireframeApp, including a new codec accessor and extended wireframe_testing helpers and tests.
New Features:
Enhancements:
Documentation:
Tests: