Extend tracing tests: cover all find_footnote_end branches and add end-to-end traced wrapping tests

[coderabbitai]

Background

PR #303 added tracing instrumentation to the inline-wrapping token- and fragment-classification pipeline. A post-merge review identified two testing gaps that are out of scope for that PR.

Raised by @leynos.

---

Gap 1 — find_footnote_end branch coverage (error)

find_footnote_end emits three distinct trace! events:

• prefix_mismatch — input does not begin with [^
• footnote_label_span_recognised — closing ] found; span computed
• unterminated_bracket — bracket never closed

The existing tracing_tests module in src/wrap/tokenize/parsing.rs covers only the prefix_mismatch path. Add #[traced_test] tests for the remaining two branches, asserting the expected event messages are emitted:

• Call find_footnote_end with a well-formed [^label] input and assert logs_contain("footnote label span recognised").
• Call find_footnote_end with an unterminated [^label input (no closing ]) and assert logs_contain("unterminated_bracket").

---

Gap 2 — end-to-end tracing tests through the public API (warning)

All current tracing tests exercise internal helpers directly. Add at least one integration-level test that:

1. Calls wrap_text (the library's public entry point) with content that contains a footnote reference, e.g. "Some text.[^1]".
2. Uses #[traced_test] so a subscriber is installed.
3. Asserts that the expected classification debug event (e.g. logs_contain("fragment classified") and logs_contain("FootnoteRef")) is emitted during the wrapping pipeline.

This confirms that the instrumentation is reachable through the public API and not accidentally gated away.

---

References

• PR Add observability for inline wrapping token classification (#296) #303
• Issue Add observability infrastructure for inline-wrapping token classification #296

[coderabbitai]

🔗 Related PRs

#276 - Cli matrix testing [merged]
#280 - Keep GFM footnote references atomic (#277) [merged]
#294 - Keep link reference definitions verbatim during wrap (#292) [merged]
#295 - Couple opening brackets with following inline code spans (#293) [merged]
#301 - Keep GFM footnote references with preceding code and link spans (#299) [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

✅ Successfully generated implementation plan.

💡 Use @coderabbitai <feedback> to replan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[coderabbitai]

Coding Plan

Summary

Add the single genuinely-missing direct traced test for the footnote_label_span_recognised branch in parsing_tests.rs, mirroring the existing sibling tests.

Assert the string exactly as emitted ("recognized", Oxford -ize), rejecting the ticket's -ised variant to keep this a pure test change.

Add the first tests/ integration test using tracing-test, driving wrap_text with "Some text.[^1]" to prove the fragment classified/FootnoteRef event survives through the public API.

Reuse existing dev-dependencies and module registrations — no Cargo or wiring changes needed.

Design Choices

Design Choice 1: Which spelling should the footnote_label_span assertion match?

Options Considered:

1. Assert the string exactly as emitted today ("footnote label span recognized"), leaving production code untouched.
2. Rename the production message to "footnote label span recognised" and assert that, changing both source and the existing indirect test.

Chosen Option: 1

Rationale: The repository standard is en-GB-oxendict (-ize), so "recognized" is already correct house style; asserting the emitted string keeps this a pure test-coverage change with zero production churn.

Design Choice 2: The unterminated_bracket branch already has a direct test.

Options Considered:

1. Add only the genuinely missing direct test for footnote_label_span_recognised; leave the existing unterminated_bracket test as-is.
2. Duplicate the unterminated_bracket test to literally match the ticket wording.

Chosen Option: 1

Rationale: Avoid redundant tests; the unterminated_bracket branch is already directly covered, so add only the one missing direct case.

💡 User Tips

Regenerate the plan with different choices with @coderabbitai <feedback>.

Implementation Steps

Phase 1: Complete find_footnote_end branch coverage

Fill the single remaining gap in the helper's traced-branch coverage by adding a direct-call test for the footnote_label_span_recognised path, mirroring the established style of the sibling prefix_mismatch and unterminated_bracket tests.

Add a direct traced test for the recognised-span branch

Verify that a well-formed footnote label emits the span-recognised trace event with its structured fields, invoked directly against the helper rather than through parse_link_or_image.

• Add a new #[traced_test] #[test] function to mod tracing_tests in src/wrap/tokenize/parsing_tests.rs, placed alongside find_footnote_end_logs_prefix_mismatch and find_footnote_end_logs_unterminated_bracket.
• Call find_footnote_end directly with a well-formed input such as "[^4] tail" at offset 0 to exercise the closing-] branch.
• Assert logs_contain("footnote label span recognized") plus the structured field fragments "start=", "end=", and "token_length=4", matching the existing indirect assertions in parse_link_or_image_logs_footnote_label_span.
• Assert the content-free policy holds by checking !logs_contain("[^4]"), consistent with the module's other cases.
• Leave the existing find_footnote_end_logs_unterminated_bracket and find_footnote_end_logs_prefix_mismatch tests untouched — both branches remain directly covered.

🤖 Prompt for AI agents

Implement Phase 1: close the last gap in direct-call test coverage for the
`find_footnote_end` helper's traced branches.

- In `src/wrap/tokenize/parsing_tests.rs`, inside `mod tracing_tests`, add one
new `#[traced_test]` `#[test]` function, placed alongside the existing
`find_footnote_end_logs_prefix_mismatch` and
`find_footnote_end_logs_unterminated_bracket` tests.
- Call `find_footnote_end` directly (not via `parse_link_or_image`) with a
well-formed input such as `"[^4] tail"` and offset `0`, exercising the
closing-`]` branch.
- Assert `logs_contain("footnote label span recognized")` — use the exact
emitted spelling with `-ized` (Oxford `-ize`), matching production code exactly;
do not use `"recognised"`.
- Also assert the structured field fragments `"start="`, `"end="`, and
`"token_length=4"`, mirroring the assertions already used in
`parse_link_or_image_logs_footnote_label_span`.
- Assert `!logs_contain("[^4]")` to uphold the content-free logging convention
used elsewhere in the module.
- Do not touch, duplicate, or rewrite the existing
`find_footnote_end_logs_unterminated_bracket` or
`find_footnote_end_logs_prefix_mismatch` tests — those branches are already
directly covered.
- Make no production code changes; this is a test-only addition.

Phase 2: End-to-end traced wrapping test through the public API

Prove the fragment-classification instrumentation is reachable through the public surface by driving wrap_text with footnote content under a captured subscriber. This becomes the first tests/ integration test to use tracing-test.

Add a traced integration test exercising wrap_text

Confirm that wrapping a paragraph containing a footnote reference emits the fragment classified DEBUG event with a FootnoteRef kind.

• Extend tests/wrap_unit/footnotes.rs (already the direct-wrap_text footnote home) with use tracing_test::traced_test; and a new #[traced_test] #[test].
• Build input lines containing a footnote suffix such as vec!["Some text.[^1]".to_string()] and call wrap_text(&input, 80), discarding the output.
• Assert logs_contain("fragment classified") and logs_contain("FootnoteRef") to prove the classification event fires through the public pipeline.
• Optionally reinforce the content-free convention with logs_contain("kind=FootnoteRef") (the emitted field form) to tighten the assertion.
• No Cargo or module-registration changes are required: tracing-test is already a dev-dependency and tests/wrap_unit/footnotes.rs is already registered in tests/wrap_unit.rs.

🤖 Prompt for AI agents

Implement Phase 2: add the first `tests/` integration test using `tracing-test`,
proving the fragment-classification event is reachable end-to-end through the
public `wrap_text` API.

- In `tests/wrap_unit/footnotes.rs`, add `use tracing_test::traced_test;` at the
top alongside existing imports.
- Add a new `#[traced_test]` `#[test]` function that builds input such as
`vec!["Some text.[^1]".to_string()]`, calls `wrap_text(&input, 80)`, and
discards the returned output.
- Assert `logs_contain("fragment classified")` and `logs_contain("FootnoteRef")`
to confirm the DEBUG event fires through the public wrapping pipeline.
- Optionally strengthen the assertion further with
`logs_contain("kind=FootnoteRef")` to match the emitted field form and reinforce
the content-free logging convention.
- Make no Cargo.toml or module-registration changes — `tracing-test` is already
a dev-dependency, and `tests/wrap_unit/footnotes.rs` is already wired into
`tests/wrap_unit.rs`.
- Make no production code changes; this is a test-only addition.

Research

Codebase Summary

find_footnote_end is a module-private helper in src/wrap/tokenize/parsing.rs, instrumented at TRACE level and emitting three branch events: prefix_mismatch, footnote label span recognized, and unterminated_bracket. Its unit tests live in src/wrap/tokenize/parsing_tests.rs (loaded via #[path] from parsing.rs), inside a mod tracing_tests block that already uses tracing_test::traced_test and the injected logs_contain helper.

The public wrapping entry point is pub fn wrap_text(lines: &[String], width: usize) -> Vec<String> in src/wrap.rs, re-exported from src/lib.rs. During wrapping, InlineFragment::new (in src/wrap/inline/fragment.rs) emits a DEBUG fragment classified event carrying token, truncated, and kind fields.

tracing-test = \"0.2\" is already a dev-dependency, so no Cargo changes are required.

File-Level Change Summary

• src/wrap/tokenize/parsing_tests.rs — add one #[traced_test] function to mod tracing_tests for the direct footnote_label_span_recognised branch. (Note: the ticket refers to parsing.rs, but the tests physically live in parsing_tests.rs, included via #[path].)
• tests/wrap_unit/footnotes.rs — add use tracing_test::traced_test; and one end-to-end #[traced_test] calling wrap_text with footnote content.
• No changes to production code, Cargo.toml, or module-registration files.

Follow-up Agent Prompt

Add two tracing tests only; change no production code.

1. In src/wrap/tokenize/parsing_tests.rs, inside `mod tracing_tests`, add a
   #[traced_test] #[test] that calls find_footnote_end(\"[^4] tail\", 0) directly
   and asserts logs_contain(\"footnote label span recognized\"), \"start=\", \"end=\",
   \"token_length=4\", and !logs_contain(\"[^4]\"). Match the exact emitted spelling
   \"recognized\" (Oxford -ize); do NOT use \"recognised\".

2. In tests/wrap_unit/footnotes.rs, add `use tracing_test::traced_test;` and a
   #[traced_test] #[test] that calls wrap_text(&vec![\"Some text.[^1]\".to_string()], 80)
   and asserts logs_contain(\"fragment classified\") and logs_contain(\"FootnoteRef\").

Do not duplicate the existing find_footnote_end_logs_unterminated_bracket test — that
branch is already covered directly. Run the test suite and confirm both new tests pass.

---

🚀 Next Steps

🤖 All AI agent prompts combined

Task: 1

Implement Phase 1: close the last gap in direct-call test coverage for the
`find_footnote_end` helper's traced branches.

- In `src/wrap/tokenize/parsing_tests.rs`, inside `mod tracing_tests`, add one
new `#[traced_test]` `#[test]` function, placed alongside the existing
`find_footnote_end_logs_prefix_mismatch` and
`find_footnote_end_logs_unterminated_bracket` tests.
- Call `find_footnote_end` directly (not via `parse_link_or_image`) with a
well-formed input such as `"[^4] tail"` and offset `0`, exercising the
closing-`]` branch.
- Assert `logs_contain("footnote label span recognized")` — use the exact
emitted spelling with `-ized` (Oxford `-ize`), matching production code exactly;
do not use `"recognised"`.
- Also assert the structured field fragments `"start="`, `"end="`, and
`"token_length=4"`, mirroring the assertions already used in
`parse_link_or_image_logs_footnote_label_span`.
- Assert `!logs_contain("[^4]")` to uphold the content-free logging convention
used elsewhere in the module.
- Do not touch, duplicate, or rewrite the existing
`find_footnote_end_logs_unterminated_bracket` or
`find_footnote_end_logs_prefix_mismatch` tests — those branches are already
directly covered.
- Make no production code changes; this is a test-only addition.
===============================================================================

Task: 2

Implement Phase 2: add the first `tests/` integration test using `tracing-test`,
proving the fragment-classification event is reachable end-to-end through the
public `wrap_text` API.

- In `tests/wrap_unit/footnotes.rs`, add `use tracing_test::traced_test;` at the
top alongside existing imports.
- Add a new `#[traced_test]` `#[test]` function that builds input such as
`vec!["Some text.[^1]".to_string()]`, calls `wrap_text(&input, 80)`, and
discards the returned output.
- Assert `logs_contain("fragment classified")` and `logs_contain("FootnoteRef")`
to confirm the DEBUG event fires through the public wrapping pipeline.
- Optionally strengthen the assertion further with
`logs_contain("kind=FootnoteRef")` to match the emitted field form and reinforce
the content-free logging convention.
- Make no Cargo.toml or module-registration changes — `tracing-test` is already
a dev-dependency, and `tests/wrap_unit/footnotes.rs` is already wired into
`tests/wrap_unit.rs`.
- Make no production code changes; this is a test-only addition.

💡 Iterate on the plan with: `@coderabbitai` <feedback>

Example Feedback
- `@coderabbitai` You can skip phase 3. Add a simple unit test case for phase 2.
- `@coderabbitai` For design choice 1 go ahead with option 3 and replan.

---

💬 Have feedback or questions? Drop into our discord!