Consolidate common test setup with rstest fixtures

[coderabbitai]

Issue Description

The test suite currently has repetitive setup code where each test re-creates default MessageRequest and Payload instances. This repetition could be eliminated by using rstest fixtures to provide common test setup.

Current Situation

• Tests manually recreate MessageRequest and Payload instances
• Lines 52-59 in test files show this pattern
• Makes it harder to add common setup like tracing spans later

Proposed Solution
Consider using rstest fixtures to provide common test setup, which would:

• Eliminate code duplication
• Make tests more maintainable
• Simplify adding common setup elements in the future
• Align with project testing guidelines

Context

• Referenced from PR: Add usage examples to public functions #161
• Original comment: Add usage examples to public functions #161 (comment)
• Requested by: @leynos

This enhancement would improve test maintainability and follow DRY principles.

[leynos]

@coderabbitai is this issue still relevant?

[coderabbitai]

Tip

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

🧩 Analysis chain

Let me check the details of issue #170 to understand what it's about and then examine the current state of the codebase.

---

🏁 Script executed:

#!/bin/bash
# Get details about issue #170
gh issue view 170 --json title,body,state,labels,assignees,createdAt,updatedAt

Length of output: 1303

---

Now let me examine the current test files to see if this repetitive setup code still exists and whether rstest fixtures have been implemented.

---

🏁 Script executed:

#!/bin/bash
# Find test files in the codebase
fd -t f -e rs | grep -E "(test|spec)" | head -10

# Look for MessageRequest and Payload in test files
rg "MessageRequest\|Payload" --type rust -A 3 -B 3

# Check if rstest is being used
rg "rstest" --type rust -A 2 -B 2

Length of output: 13094

---

Let me search more specifically for the repetitive setup patterns mentioned in the issue, and also look for any types that might have been renamed.

---

🏁 Script executed:

#!/bin/bash
# Look for any request/payload related types that might have been renamed
rg -i "request\|payload" --type rust -A 2 -B 2 | head -20

# Look for lines 52-59 in test files to see if the pattern still exists
for file in $(fd -t f -e rs | grep -E "(test|spec)"); do
    echo "=== Checking $file ==="
    sed -n '52,59p' "$file" 2>/dev/null || echo "File has fewer than 59 lines"
done | grep -A 10 -B 5 "MessageRequest\|Payload\|setup\|create"

# Check if there are any common test setup patterns that could be consolidated
rg "fn.*test.*setup\|let.*=.*new\(\)" --type rust -A 3 -B 1 | head -20

Length of output: 4931

---

Let me examine the specific test file that shows the pattern mentioned in the issue:

---

🏁 Script executed:

#!/bin/bash
# Look at the extractor.rs file to see the repetitive pattern
cat tests/extractor.rs

# Also check if there are other test files with similar patterns
rg "MessageRequest::default\|Payload::default" --type rust -A 5 -B 5

Length of output: 3111

---

@leynos Yes, this issue is still relevant!

Looking at the current codebase, the repetitive setup pattern described in issue #170 is still present in tests/extractor.rs. I can see multiple tests that manually create MessageRequest::default() and Payload::default() instances:

Lines 55-57 (the specific pattern mentioned in the issue):

fn shared_state_extractor() {
    let mut req = MessageRequest::default();
    req.insert_state(42u8);
    let mut payload = Payload::default();
    // ... rest of test
}

Other instances of the same pattern:

• Lines 30-31 in message_extractor_parses_and_advances()
• Lines 42-46 in connection_info_reports_peer()
• Lines 68-69 in shared_state_missing_error()

While rstest is being used extensively throughout the codebase (I found it in many test files), the specific consolidation of MessageRequest and Payload setup into fixtures hasn't been implemented yet. The issue remains open and the repetitive setup code that could benefit from rstest fixtures is still there.

The enhancement would indeed improve test maintainability by following DRY principles as originally described.

[leynos]

Closed by #188