Skip to content

Extend wireframe_testing with codec-aware drivers and app codec#484

Merged
leynos merged 3 commits intomainfrom
feature/codec-test-harness-t679ef
Feb 27, 2026
Merged

Extend wireframe_testing with codec-aware drivers and app codec#484
leynos merged 3 commits intomainfrom
feature/codec-test-harness-t679ef

Conversation

@leynos
Copy link
Copy Markdown
Owner

@leynos leynos commented Feb 26, 2026

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

  • Public API: add WireframeApp::codec(&self) -> &F to expose the configured FrameCodec.
  • wireframe_testing crate:
    • New modules: codec_ext.rs and codec_drive.rs under wireframe_testing/src/helpers.
    • New helpers:
      • encode_payloads_with_codec
      • decode_frames_with_codec
      • extract_payloads
    • New codec-aware drivers (async, additive):
      • Payload-level: drive_with_codec_payloads, drive_with_codec_payloads_with_capacity, drive_with_codec_payloads_mut, drive_with_codec_payloads_with_capacity_mut
      • Frame-level: drive_with_codec_frames, drive_with_codec_frames_with_capacity
    • Re-exports added in wireframe_testing/src/helpers.rs and wireframe_testing/src/lib.rs for public access.
  • Tests & BDD harness:
    • tests/codec_test_harness.rs (integration tests for codec drivers)
    • tests/features/codec_test_harness.feature (BDD feature description)
    • tests/fixtures/codec_test_harness.rs (BDD world, codec/app setup)
    • tests/steps/codec_test_harness_steps.rs (step definitions)
    • tests/scenarios/codec_test_harness_scenarios.rs (scenario bindings)
    • tests/fixtures/mod.rs updated to export codec_test_harness;
      tests/scenarios/mod.rs and tests/steps/mod.rs updated accordingly.
  • Documentation & roadmap:
    • docs/adr-004-pluggable-protocol-codecs.md updated with codec-aware test harness decisions.
    • docs/users-guide.md updated to document the new WireframeApp::codec accessor and wireframe_testing codec helpers.
    • docs/roadmap.md marks 9.7.1 as done.

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

  • The codec is passed explicitly to the helpers (as &F) instead of being inferred from the app, avoiding coupling to internal WireframeApp fields.
  • A dedicated public accessor (codec) on WireframeApp eases test reuse without cloning.
  • All changes are additive; existing APIs remain compatible.
  • Documentation and ADR updates reflect the new design and usage patterns.

Testing plan

  • Build and run all tests: cargo test --workspace
  • Specifically validate:
    • wireframe_testing unit tests for new helpers and drivers
    • integration tests in tests/codec_test_harness.rs
    • BDD scenarios in tests/scenarios/codec_test_harness_scenarios.rs
  • Ensure make check-fmt, make lint, and markdownlint pass after changes.

Impact

  • Adds codec-aware testing capabilities for users of wireframe_testing.
  • No breaking changes to existing public APIs; only an additive accessor in WireframeApp and new dev/testing helpers.
  • Documentation surfaces the new API and testing workflow.

Notes for reviewers

  • Verify the public API additions and ensure there are no unintended public exposure changes other than the accessor.
  • Review the new tests for correctness and avoid introducing flaky or heavy integration tests in CI.
  • Confirm that ADR/roadmap updates align with project conventions and that the new tests compile in the workspace layout.

◳ 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:

  • Expose a codec() accessor on WireframeApp to retrieve the configured FrameCodec.
  • Introduce codec-aware driver helpers in wireframe_testing for payload- and frame-level in-memory testing against arbitrary FrameCodec implementations.
  • Add generic codec helper functions to encode payloads, decode frames, and extract payload bytes for custom test compositions.

Enhancements:

  • Re-export new codec-aware helpers and drivers from wireframe_testing so they are available from the crate root.
  • Document the codec accessor and codec-aware testing workflow in the user guide and architectural decision record.
  • Add an execution plan document describing the design, constraints, and outcomes for codec-aware testing support.
  • Update ADR-004 to reflect codec-aware test harness decisions.

Documentation:

  • Update ADR-004 to record decisions around codec-aware test harness drivers and helper design.
  • Extend the user guide with examples for retrieving the codec from WireframeApp and using codec-aware wireframe_testing drivers.
  • Add an execution plan document explaining the design, constraints, and outcomes for codec-aware testing support.
  • Update the roadmap to mark codec-aware test harness work (9.7.1) as completed.

Tests:

  • Add integration tests validating codec-aware helpers and drivers with HotlineFrameCodec.
  • Add BDD fixtures, steps, scenarios, and feature definitions to exercise codec-aware drivers end-to-end.

…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>
@coderabbitai
Copy link
Copy Markdown
Contributor

coderabbitai Bot commented Feb 26, 2026

Walkthrough

Extend wireframe_testing with codec-aware helpers and drivers plus a public WireframeApp::codec() accessor; add encode/decode/extract utilities, payload- and frame-level driver variants (owned and mutable, with capacity options); supply documentation, integration tests and BDD scaffolding for codec-aware testing.

Changes

Cohort / File(s) Summary
Documentation
docs/adr-004-pluggable-protocol-codecs.md, docs/execplans/9-7-1-codec-aware-wireframe-testing.md, docs/roadmap.md, docs/users-guide.md
Add ADR section and execplan for codec-aware testing; document WireframeApp::codec() usage, codec-aware drivers, zero-copy payload patterns; mark roadmap item 9.7.1 complete.
App API
src/app/builder/codec.rs
Add pub fn codec(&self) -> &F accessor on WireframeApp (generic impl with F: FrameCodec).
Testing helpers — public exports
wireframe_testing/src/lib.rs, wireframe_testing/src/helpers.rs
Re-export new codec helpers and codec-aware driver functions; expand drive re-exports.
Testing helpers — implementations
wireframe_testing/src/helpers/codec_ext.rs, wireframe_testing/src/helpers/codec_drive.rs
Add encode_payloads_with_codec, decode_frames_with_codec, extract_payloads; add payload-level and frame-level codec-aware drivers (owned/mut, capacity variants) and internal shared logic.
Integration tests
tests/codec_test_harness.rs
Add integration tests covering encode/decode helpers, payload extraction, and end-to-end driving through an echo app asserting payload integrity and codec metadata.
BDD test suite
tests/features/codec_test_harness.feature, tests/fixtures/codec_test_harness.rs, tests/fixtures/mod.rs, tests/scenarios/codec_test_harness_scenarios.rs, tests/scenarios/mod.rs, tests/steps/codec_test_harness_steps.rs, tests/steps/mod.rs
Add feature file, a CodecTestHarnessWorld fixture, scenario bindings and step definitions to drive and verify codec-aware test flows.

Sequence Diagram

sequenceDiagram
    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
Loading

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~40 minutes

Possibly related PRs

Poem

🔧 Encode the payload, send it through the wire,
Tests drive frames and make the codecs choir,
Metadata travels, assertions gleam—
Hooks and helpers stitch the testing dream ✨

🚥 Pre-merge checks | ✅ 3
✅ Passed checks (3 passed)
Check name Status Explanation
Docstring Coverage ✅ Passed Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.
Title check ✅ Passed The title 'Extend wireframe_testing with codec-aware drivers and app codec' accurately and clearly describes the main changes: adding codec-aware drivers to wireframe_testing and exposing a codec accessor on WireframeApp.
Description check ✅ Passed The description comprehensively explains the PR's purpose, changes, and design rationale, relating directly to the changeset with clear sections covering public API additions, new modules, helpers, tests, and documentation updates.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
  • 📝 Generate docstrings (stacked PR)
  • 📝 Generate docstrings (commit on current branch)
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment
  • Commit unit tests in branch feature/codec-test-harness-t679ef

Comment @coderabbitai help to get the list of available commands and usage tips.

@sourcery-ai
Copy link
Copy Markdown
Contributor

sourcery-ai Bot commented Feb 26, 2026

Reviewer's Guide

Implements 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 flow

sequenceDiagram
    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
Loading

Class diagram for codec-aware testing helpers and WireframeApp accessor

classDiagram
    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 {
    }
Loading

File-Level Changes

Change Details Files
Expose the configured FrameCodec from WireframeApp as a public accessor for reuse in tests and callers.
  • Add codec(&self) -> &F on WireframeApp’s codec builder impl to return a reference to the configured codec
  • Keep the accessor additive and non-breaking relative to existing builder APIs
src/app/builder/codec.rs
Add generic codec-based encode/decode helpers and codec-aware driver functions to wireframe_testing and re-export them from the crate root.
  • Introduce helpers to encode payload Vec<Vec> into codec frames, decode raw bytes back into frames, and extract payload bytes from frames
  • Implement payload-level and frame-level async drivers that wrap drive_internal, handling codec-based encoding/decoding around the in-memory duplex transport
  • Wire new helpers and drivers into the helpers module tree and publicly re-export them from wireframe_testing::lib
wireframe_testing/src/helpers.rs
wireframe_testing/src/helpers/codec_ext.rs
wireframe_testing/src/helpers/codec_drive.rs
wireframe_testing/src/lib.rs
Add integration tests and rstest-bdd behavioural tests validating the codec-aware helpers and drivers with HotlineFrameCodec.
  • Create integration tests that exercise encode/decode round-trips, payload/frame driver behaviour, and mutable app reuse
  • Add a new BDD world, steps, scenarios, and feature file for codec-aware test harness behaviour and register them in the existing fixtures/steps/scenarios mod trees
tests/codec_test_harness.rs
tests/features/codec_test_harness.feature
tests/fixtures/codec_test_harness.rs
tests/steps/codec_test_harness_steps.rs
tests/scenarios/codec_test_harness_scenarios.rs
tests/fixtures/mod.rs
tests/steps/mod.rs
tests/scenarios/mod.rs
Update architectural and user-facing documentation plus the roadmap to reflect codec-aware test harness support and completion of roadmap item 9.7.1.
  • Describe the new codec accessor and codec-aware driver usage in the user guide with examples
  • Record the resolved design for codec-aware test harness drivers and helpers in ADR-004
  • Mark roadmap item 9.7.1 as completed and add an execplan documenting constraints, design, and validation steps
docs/users-guide.md
docs/adr-004-pluggable-protocol-codecs.md
docs/roadmap.md
docs/execplans/9-7-1-codec-aware-wireframe-testing.md

Tips and commands

Interacting with Sourcery

  • Trigger a new review: Comment @sourcery-ai review on the pull request.
  • Continue discussions: Reply directly to Sourcery's review comments.
  • Generate a GitHub issue from a review comment: Ask Sourcery to create an
    issue from a review comment by replying to it. You can also reply to a
    review comment with @sourcery-ai issue to create an issue from it.
  • Generate a pull request title: Write @sourcery-ai anywhere in the pull
    request title to generate a title at any time. You can also comment
    @sourcery-ai title on the pull request to (re-)generate the title at any time.
  • Generate a pull request summary: Write @sourcery-ai summary anywhere in
    the pull request body to generate a PR summary at any time exactly where you
    want it. You can also comment @sourcery-ai summary on the pull request to
    (re-)generate the summary at any time.
  • Generate reviewer's guide: Comment @sourcery-ai guide on the pull
    request to (re-)generate the reviewer's guide at any time.
  • Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
    pull request to resolve all Sourcery comments. Useful if you've already
    addressed all the comments and don't want to see them anymore.
  • Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
    request to dismiss all existing Sourcery reviews. Especially useful if you
    want to start fresh with a new review - don't forget to comment
    @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

  • Enable or disable review features such as the Sourcery-generated pull request
    summary, the reviewer's guide, and others.
  • Change the review language.
  • Add, remove or edit custom review instructions.
  • Adjust other review settings.

Getting Help

@leynos leynos marked this pull request as ready for review February 26, 2026 14:14
Copy link
Copy Markdown
Contributor

@sourcery-ai sourcery-ai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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_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.
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>

Sourcery is free for open source - if you like our reviews please consider sharing them ✨
Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.

Comment thread docs/execplans/9-7-1-codec-aware-wireframe-testing.md Outdated
Comment thread wireframe_testing/src/helpers/codec_drive.rs
Comment thread wireframe_testing/src/helpers/codec_ext.rs Outdated
Comment thread wireframe_testing/src/helpers/codec_ext.rs
Comment thread docs/execplans/9-7-1-codec-aware-wireframe-testing.md
@coderabbitai coderabbitai Bot added the codex label Feb 26, 2026
Copy link
Copy Markdown

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 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".

Comment thread wireframe_testing/src/helpers/codec_ext.rs
Copy link
Copy Markdown
Contributor

@coderabbitai coderabbitai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

📥 Commits

Reviewing files that changed from the base of the PR and between bfe299b and 0270607.

⛔ Files ignored due to path filters (1)
  • wireframe_testing/Cargo.lock is excluded by !**/*.lock
📒 Files selected for processing (17)
  • docs/adr-004-pluggable-protocol-codecs.md
  • docs/execplans/9-7-1-codec-aware-wireframe-testing.md
  • docs/roadmap.md
  • docs/users-guide.md
  • src/app/builder/codec.rs
  • tests/codec_test_harness.rs
  • tests/features/codec_test_harness.feature
  • tests/fixtures/codec_test_harness.rs
  • tests/fixtures/mod.rs
  • tests/scenarios/codec_test_harness_scenarios.rs
  • tests/scenarios/mod.rs
  • tests/steps/codec_test_harness_steps.rs
  • tests/steps/mod.rs
  • wireframe_testing/src/helpers.rs
  • wireframe_testing/src/helpers/codec_drive.rs
  • wireframe_testing/src/helpers/codec_ext.rs
  • wireframe_testing/src/lib.rs

Comment thread docs/adr-004-pluggable-protocol-codecs.md Outdated
Comment thread docs/execplans/9-7-1-codec-aware-wireframe-testing.md Outdated
Comment thread docs/users-guide.md Outdated
Comment thread docs/users-guide.md Outdated
Comment thread wireframe_testing/src/helpers/codec_drive.rs Outdated
Comment thread wireframe_testing/src/helpers/codec_ext.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>
Copy link
Copy Markdown
Contributor

@coderabbitai coderabbitai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

♻️ Duplicate comments (1)
docs/execplans/9-7-1-codec-aware-wireframe-testing.md (1)

38-40: ⚠️ Potential issue | 🟡 Minor

Align 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.

🧾 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.
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."

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

📥 Commits

Reviewing files that changed from the base of the PR and between 0270607 and da93f08.

📒 Files selected for processing (5)
  • docs/adr-004-pluggable-protocol-codecs.md
  • docs/execplans/9-7-1-codec-aware-wireframe-testing.md
  • docs/users-guide.md
  • wireframe_testing/src/helpers/codec_drive.rs
  • wireframe_testing/src/helpers/codec_ext.rs

Comment thread docs/users-guide.md
@leynos
Copy link
Copy Markdown
Owner Author

leynos commented Feb 26, 2026

@coderabbitai Have the following now been resolved?

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>

@coderabbitai
Copy link
Copy Markdown
Contributor

coderabbitai Bot commented Feb 26, 2026

Tip

For best results, initiate chat on the files or code changes.

🧩 Analysis chain

I'll check the current state of the files to verify whether those review comments have been addressed.


🏁 Script executed:

#!/bin/bash

# Check the execplan document for the test path reference (Comment 1)
echo "=== Checking execplan for test path reference (Comment 1) ==="
cat docs/execplans/9-7-1-codec-aware-wireframe-testing.md | grep -A 3 "Quality criteria"

echo -e "\n=== Checking execplan for BDD acronym expansion (Comment 5) ==="
cat docs/execplans/9-7-1-codec-aware-wireframe-testing.md | grep -A 2 "BDD test pattern"

echo -e "\n=== Checking codec_drive.rs for internal helper (Comments 2 and Overall 1) ==="
# Look for drive_codec_frames_internal or similar internal helper
rg -n "drive.*internal|drive_frames_impl" wireframe_testing/src/helpers/codec_drive.rs

echo -e "\n=== Checking codec_ext.rs for .unwrap() usage (Comments 3 and 4) ==="
rg -n "\.unwrap\(\)" wireframe_testing/src/helpers/codec_ext.rs

echo -e "\n=== Checking for io::Error::other usage (Overall Comment 2) ==="
rg -n "io::Error::other" wireframe_testing/ tests/

Length of output: 9094


Let me check the MSRV and look more closely at the BDD acronym situation:


🏁 Script executed:

#!/bin/bash

# Check MSRV in Cargo.toml files
echo "=== Checking MSRV (rust-version) in Cargo.toml files ==="
fd -t f "Cargo.toml" -x grep -H "rust-version"

# Check when io::Error::other was stabilized and compare
echo -e "\n=== Checking broader context around BDD acronym ==="
# Get more context around the BDD section
sed -n '215,230p' docs/execplans/9-7-1-codec-aware-wireframe-testing.md

Length of output: 924


🏁 Script executed:

#!/bin/bash

# Check if the new codec helper files use io::Error::other
echo "=== Checking codec_ext.rs and codec_drive.rs for io::Error::other ==="
rg -n "io::Error" wireframe_testing/src/helpers/codec_ext.rs wireframe_testing/src/helpers/codec_drive.rs

# Get more lines around the BDD heading to see if it's expanded elsewhere
echo -e "\n=== Searching for BDD expansion in the execplan ==="
rg -n "BDD|Behaviour.*driven|Behavior.*driven" docs/execplans/9-7-1-codec-aware-wireframe-testing.md | head -20

Length of output: 2098


🏁 Script executed:

#!/bin/bash

# Check if BDD is expanded before line 222 in the execplan
echo "=== Checking for BDD expansion before line 222 ==="
head -221 docs/execplans/9-7-1-codec-aware-wireframe-testing.md | rg -n "BDD|Behaviour|Behavior" | tail -10

# Also check the first occurrence of BDD
echo -e "\n=== First few occurrences of BDD in the document ==="
head -110 docs/execplans/9-7-1-codec-aware-wireframe-testing.md | rg -n "BDD"

Length of output: 683


🏁 Script executed:

#!/bin/bash

# Get the full context of line 104 to see if BDD is properly expanded
echo "=== Full context around line 104 where BDD first appears ==="
sed -n '100,108p' docs/execplans/9-7-1-codec-aware-wireframe-testing.md

# Double-check what error construction pattern is used in the NEW codec helpers
echo -e "\n=== Error construction in NEW codec_ext.rs ==="
rg -A 2 "io::Error::new" wireframe_testing/src/helpers/codec_ext.rs | head -20

Length of output: 977


@leynos, yes! All of those review comments have been resolved. Here's the verification:

✅ All Issues Addressed

Comment 1: Test path in execplan

RESOLVED — The quality criteria now correctly references tests/codec_test_harness.rs instead of the outdated wireframe_testing/src/helpers/tests/codec_drive_tests.rs path.

Comment 2 & Overall Comment 1: Extract shared internal helper

RESOLVED — The drive_codec_frames_internal function was created at line 32 of codec_drive.rs. It centralises the encode→drive_internal→decode pipeline, and both frame-level and payload-level drivers delegate to it. This eliminates the duplication and behavioural drift risk you identified.

Comments 3 & 4: .unwrap().expect() in doc examples

RESOLVED — No .unwrap() calls remain in codec_ext.rs. The doc examples now use .expect(...) with descriptive messages, complying with the coding guidelines.

Comment 5: BDD acronym expansion

RESOLVED — BDD is expanded on its first use at line 104: "behaviour-driven development (BDD)". The heading at line 222 that reads "### BDD test pattern" is therefore fine, as the acronym was already defined earlier in the document.

Overall Comment 2: io::Error::other(...) compatibility

RESOLVED — The new codec helper modules (codec_ext.rs and codec_drive.rs) use the more compatible io::Error::new(io::ErrorKind::InvalidData, ...) pattern throughout, avoiding any MSRV concerns. While other parts of the codebase use io::Error::other, the code introduced in this PR uses the safer construction.


All seven review points have been addressed. The PR is now compliant with the original feedback.

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>
@leynos leynos changed the title Extend wireframe_testing with codec-aware drivers (9.7.1) Extend wireframe_testing with codec-aware drivers and app codec Feb 26, 2026
@leynos leynos merged commit e21209e into main Feb 27, 2026
6 checks passed
@leynos leynos deleted the feature/codec-test-harness-t679ef branch February 27, 2026 02:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant