Fix SharedBuf encapsulation

[leynos]

Summary

• hide the shared buffer inside SharedBuf
• add constructor and accessor
• use new() in tests
• document shared buffer design

closes #100

Testing

• make fmt
• RUSTC_WRAPPER= make lint
• RUSTC_WRAPPER= make typecheck
• RUSTC_WRAPPER= make test
• make markdownlint
• make nixie (fails: Cannot find module '../bidi/BrowserConnector.js')

---

https://chatgpt.com/codex/tasks/task_e_6883efb646188322beff6ff9e95b712a

Summary by Sourcery

Encapsulate the SharedBuf internals behind a private field and introduce a stable API (new, default, contents), while updating tests and documentation to align with the new abstraction.

New Features:

• Add SharedBuf::new constructor, Default implementation, and contents() accessor for inspecting buffer contents

Enhancements:

• Encapsulate SharedBuf’s inner Arc<Mutex<Vec>> behind a private field to enforce encapsulation

Documentation:

• Document SharedBuf design and usage in testing docs and rewrap paragraphs for readability

Tests:

• Update tests to use SharedBuf::new or Default instead of the tuple struct constructor

[sourcery-ai]

Reviewer's Guide

Encapsulate SharedBuf’s internal Arc<Mutex<Vec>> behind a private field with a new constructor and accessor, update all tests to use the SharedBuf::new API, and refine markdown formatting in the rstest fixtures guide.

Class diagram for updated SharedBuf encapsulation

classDiagram
    class SharedBuf {
        - Arc<Mutex<Vec<u8>>> buffer
        + new(buf: Vec<u8>) SharedBuf
        + buffer() -> Arc<Mutex<Vec<u8>>>
        + default() SharedBuf
        + contents() -> Vec<u8>
    }

Loading

File-Level Changes

Change	Details	Files
Encapsulate SharedBuf internals and add constructors/accessors	Convert SharedBuf from a tuple struct to a struct with a private buffer field Introduce SharedBuf::new, contents method, and Default implementation Update Write impl to lock and write via the private buffer field Add doc comments explaining the encapsulation and usage	rust_extension/tests/test_utils/shared_buffer.rs
Update test code to use SharedBuf::new API	Replace direct SharedBuf(Arc::clone(...)) instantiations with SharedBuf::new(...) Adjust imports and calls across logger, file handler, proptest, fixture, and stream handler tests	rust_extension/tests/logger_tests.rs rust_extension/tests/file_handler_tests.rs rust_extension/tests/heavy/prop_stream_handler.rs rust_extension/tests/test_utils/fixtures.rs rust_extension/tests/stream_handler_tests.rs
Refine markdown formatting in rstest fixtures guide	Adjust line breaks and paragraph wrapping for improved readability Update code fences and spacing consistency Reformat table columns and alignment in the comparison section	docs/rust-testing-with-rstest-fixtures.md

Assessment against linked issues

Issue	Objective	Addressed	Explanation
#100	Make the inner Arc<Mutex<Vec>> field of SharedBuf private to improve encapsulation.	✅
#100	Provide appropriate constructor and accessor methods for SharedBuf to maintain functionality and test compatibility.	✅
#100	Update test code and documentation to use the new SharedBuf API and document the encapsulation design.	✅

Possibly linked issues

• Improve encapsulation of SharedBuf struct in test utilities #100: The PR makes SharedBuf's buffer private and adds constructor/accessor methods, directly addressing the encapsulation issue.

---

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

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[coderabbitai]

Summary by CodeRabbit

• Documentation

  • Improved formatting, readability, and clarity in the Rust testing guide without changing technical content.

• Refactor

  • Updated buffer wrapper usage in tests to use a constructor method for improved encapsulation.
  • Changed buffer wrapper from a tuple struct to a named-field struct with private fields.
  • Introduced new methods for buffer access and default instantiation, enhancing test utility code.

Walkthrough

Refactor the SharedBuf struct in test utilities from a tuple struct with a public field to a named-field struct with a private buffer, adding explicit constructor and accessor methods. Update all test code to instantiate SharedBuf via its new constructor. Edit documentation for formatting and clarity without altering technical content.

Changes

File(s)	Change Summary
rust_extension/tests/test_utils/shared_buffer.rs	Refactor SharedBuf to a named-field struct with private buffer; add new constructor and contents accessor; update trait impls.
rust_extension/tests/test_utils/fixtures.rs	Update fixture functions to instantiate SharedBuf using SharedBuf::new instead of direct tuple struct construction.
rust_extension/tests/file_handler_tests.rs rust_extension/tests/logger_tests.rs rust_extension/tests/stream_handler_tests.rs rust_extension/tests/heavy/prop_stream_handler.rs	Replace all direct SharedBuf tuple struct construction with SharedBuf::new in test and fixture code.
docs/rust-testing-with-rstest-fixtures.md	Reformat and clarify documentation: improve line wrapping, phrasing, and code block language tags; no technical content changed.

Sequence Diagram(s)

sequenceDiagram
    participant Test as Test Function
    participant Arc as Arc<Mutex<Vec<u8>>>
    participant SharedBuf as SharedBuf
    participant Handler as FemtoStreamHandler

    Test->>Arc: Create buffer
    Test->>SharedBuf: SharedBuf::new(Arc)
    Test->>Handler: FemtoStreamHandler::new(SharedBuf, ...)
    Handler->>SharedBuf: Write data
    SharedBuf->>Arc: Lock and mutate Vec<u8>

Loading

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~8 minutes

Possibly related PRs

• Fix inline feedback #97: Refactored the shared buffer helper module, originally introducing SharedBuf as a tuple struct; this PR continues and refines that abstraction.
• Refactor tests to share buffer impl #119: Refactored tests to use a centralised SharedBuf implementation; both PRs modify how SharedBuf is handled in tests.
• Format markdown documentation netsuke#22: Applied similar formatting and phrasing improvements to the same documentation file, aligning with the documentation edits in this PR.

Poem

Encapsulate the buffer, lock it up tight,
No more public fields in shared test light.
With new and buffer, the interface is clear,
Rusty test code marches, refactored and dear.
Docs now shine, code blocks aligned—
A buffer’s new chapter, robustly defined!
🦀✨

---

📜 Recent review details

Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between d807e9b and 2a06699.

📒 Files selected for processing (2)

• docs/rust-testing-with-rstest-fixtures.md (33 hunks)
• rust_extension/tests/test_utils/shared_buffer.rs (2 hunks)

🧰 Additional context used

📓 Path-based instructions (5)

**/*.rs

📄 CodeRabbit Inference Engine (AGENTS.md)

**/*.rs: Run make fmt, make lint, make typecheck, and make test before committing Rust code.
Clippy warnings MUST be disallowed in Rust code.
Where a function is too long in Rust, extract meaningfully named helper functions adhering to separation of concerns and CQRS.
Where a function has too many parameters in Rust, group related parameters in meaningfully named structs.
Where a function is returning a large error in Rust, consider using Arc to reduce the amount of data returned.
Write unit and behavioural tests for new functionality in Rust. Run both before and after making any change.
Document public APIs in Rust using Rustdoc comments (///) so documentation can be generated with cargo doc.
Prefer immutable data and avoid unnecessary mut bindings in Rust.
Handle errors with the Result type in Rust instead of panicking where feasible.
Avoid unsafe code in Rust unless absolutely necessary and document any usage clearly.

Files:

• rust_extension/tests/test_utils/shared_buffer.rs

---

⚙️ CodeRabbit Configuration File

**/*.rs: * Seek to keep the cyclomatic complexity of functions no more than 12.

• Adhere to single responsibility and CQRS

• Place function attributes after doc comments.

• Do not use return in single-line functions.

• Move conditionals with >2 branches into a predicate function.

• Avoid unsafe unless absolutely necessary.

• Every module must begin with a //! doc comment that explains the module's purpose and utility.

• Comments and docs must follow en-GB-oxendict (-ize / -our) spelling and grammar

• Lints must not be silenced except as a last resort.

  • #[allow] is forbidden.
  • Only narrowly scoped #[expect(lint, reason = "...")] is allowed.
  • No lint groups, no blanket or file-wide suppression.
  • Include FIXME: with link if a fix is expected.

• Use rstest fixtures for shared setup and to avoid repetition between tests.

• Replace duplicated tests with #[rstest(...)] parameterised cases.

• Prefer mockall for mocks/stubs.

• Prefer .expect() over .unwrap()

• Ensure that any API or behavioural changes are reflected in the documentation in docs/

• Ensure that any completed roadmap steps are recorded in the appropriate roadmap in docs/

• Files must not exceed 400 lines in length

  • Large modules must be decomposed
  • Long match statements or dispatch tables should be decomposed by domain and collocated with targets
  • Large blocks of inline data (e.g., test fixtures, constants or templates) must be moved to external files and inlined at compile-time or loaded at run-time.

Files:

• rust_extension/tests/test_utils/shared_buffer.rs

docs/**/*.md

📄 CodeRabbit Inference Engine (docs/documentation-style-guide.md)

docs/**/*.md: Use British English based on the Oxford English Dictionary (en-oxendict) for documentation, except when US spelling is used in an API (e.g., color), and spell the project licence file as LICENSE.
Use the Oxford comma in documentation.
Treat company names as collective nouns (e.g., 'Lille Industries are expanding') in documentation.
Write headings in sentence case in documentation.
Use Markdown headings (#, ##, ###, etc.) in order without skipping levels.
Follow markdownlint recommendations for Markdown files.
Provide code blocks and lists using standard Markdown syntax.
Always provide a language identifier for fenced code blocks in Markdown; use plaintext for non-code text.
Use - as the first level bullet and renumber lists when items change in Markdown.
Prefer inline links using [text](url) or angle brackets around the URL in Markdown.
Ensure blank lines before and after bulleted lists and fenced code blocks in Markdown.
Ensure tables in Markdown have a delimiter line below the header row.
Expand any uncommon acronym on first use in documentation (e.g., Continuous Integration (CI)).
Wrap paragraphs at 80 columns in documentation.
Wrap code at 120 columns in documentation.
Do not wrap tables in documentation.
Use footnotes referenced with [^label] in documentation.
Include Mermaid diagrams in documentation where it adds clarity.
When embedding figures in documentation, use ![alt text](path/to/image) and provide concise alt text describing the content.
Add a short description before each Mermaid diagram in documentation so screen readers can understand it.

The logging class diagram should be maintained in Markdown documentation using Mermaid syntax for clarity and up-to-date reference.

docs/**/*.md: Use the markdown files within the docs/ directory as a knowledge base and source of truth for project requirements, dependency choices, and architectural decisions.
Proactively update the relevant file(s) in the docs/ directory to r...

Files:

• docs/rust-testing-with-rstest-fixtures.md

**/*.md

📄 CodeRabbit Inference Engine (AGENTS.md)

**/*.md: For Markdown files (.md only): Run make markdownlint or use integrated editor linting.
For Markdown files (.md only): Validate Mermaid diagrams with make nixie.

Files:

• docs/rust-testing-with-rstest-fixtures.md

---

⚙️ CodeRabbit Configuration File

**/*.md: * Avoid 2nd person or 1st person pronouns ("I", "you", "we")

• Use en-GB-oxendict (-ize / -our) spelling and grammar
• Paragraphs and bullets must be wrapped to 80 columns, except where a long URL would prevent this (in which case, silence MD013 for that line)
• Code blocks should be wrapped to 120 columns.
• Headings must not be wrapped.
• Documents must start with a level 1 heading
• Headings must correctly increase or decrease by no more than one level at a time
• Use GitHub-flavoured Markdown style for footnotes and endnotes.
• Numbered footnotes must be numbered by order of appearance in the document.

Files:

• docs/rust-testing-with-rstest-fixtures.md

docs/**/*.{py,rs,md}

📄 CodeRabbit Inference Engine (docs/dev-workflow.md)

docs/**/*.{py,rs,md}: Run make fmt to format Python, Rust, and Markdown sources
Run make check-fmt to verify formatting of Python, Rust, and Markdown sources without modifying files

Files:

• docs/rust-testing-with-rstest-fixtures.md

{README.md,docs/**}

📄 CodeRabbit Inference Engine (.rules/python-00.mdc)

Colocate documentation (README.md or docs/) near reusable packages and include usage examples

Files:

• docs/rust-testing-with-rstest-fixtures.md

🧠 Learnings (1)

docs/rust-testing-with-rstest-fixtures.md (119)

Learnt from: CR
PR: leynos/mxd#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T23:40:09.111Z
Learning: In Rust, the rstest crate provides a declarative, macro-based approach to fixture-based and parameterized testing, reducing boilerplate and improving test readability.

Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T00:05:36.857Z
Learning: In Rust, the rstest crate enables fixture-based and parameterized testing using procedural macros like #[rstest] and #[fixture], allowing dependencies to be injected as function arguments for improved readability and reduced boilerplate.

Learnt from: CR
PR: leynos/mxd#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T23:40:48.640Z
Learning: In Rust, the rstest crate enables fixture-based and parameterized testing using procedural macros such as #[rstest] and #[fixture], allowing for declarative test setup and dependency injection.

Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T00:05:37.557Z
Learning: In Rust, the rstest crate enables declarative fixture-based and parameterized testing using procedural macros like #[rstest] and #[fixture], which inject dependencies as function arguments and generate multiple test cases from a single function.

Learnt from: CR
PR: leynos/lille#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T18:32:30.955Z
Learning: In Rust, the rstest crate enables fixture-based and parameterized testing using procedural macros like #[rstest] and #[fixture], allowing dependencies to be injected into test functions as arguments.

Learnt from: CR
PR: leynos/mdtablefix#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T23:09:41.600Z
Learning: In Rust, the rstest crate enables fixture-based and parameterized testing using procedural macros like #[rstest] and #[fixture], which inject dependencies into test functions by matching argument names to fixture functions.

Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T00:05:36.858Z
Learning: Compared to standard Rust #[test], rstest provides declarative fixture injection and parameterization, reducing boilerplate and improving test clarity, especially for complex setups and input combinations.

Learnt from: CR
PR: leynos/lille#0
File: docs/testing-differential-datalog-rulesets.md:0-0
Timestamp: 2025-06-24T18:33:02.407Z
Learning: The rstest crate is recommended for organizing DDlog tests in Rust, providing fixtures for common setup (such as initializing the DDlog program) and parameterized tests to reduce boilerplate and improve readability.

Learnt from: CR
PR: leynos/lille#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-20T12:06:42.577Z
Learning: Use rstest for tests with complex setup, parameterization, or where improved readability and DRY principles are desired; use standard #[test] for simple, isolated unit tests.

Learnt from: CR
PR: leynos/femtologging#0
File: docs/contents.md:0-0
Timestamp: 2025-07-20T17:08:06.039Z
Learning: Use the rstest crate for fixture-based tests in Rust as explained in rust-testing-with-rstest-fixtures.md

Learnt from: CR
PR: leynos/lille#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T18:32:30.955Z
Learning: Best practices for organizing rstest-based tests include: placing module-local fixtures in the module's tests submodule, sharing fixtures via a common module or crate, using descriptive names, composing small fixtures, and preferring per-test fixtures for isolation.

Learnt from: CR
PR: leynos/mdtablefix#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T23:09:41.600Z
Learning: Fixtures in rstest are Rust functions annotated with #[fixture] that encapsulate setup logic and can return any valid Rust type, including primitives, structs, or trait objects. Fixtures can depend on other fixtures by listing them as arguments.

Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T00:05:37.557Z
Learning: Fixtures in rstest are Rust functions annotated with #[fixture] that encapsulate setup logic and can return any valid Rust type, including primitives, structs, or trait objects. Fixtures can depend on other fixtures by listing them as arguments.

Learnt from: CR
PR: leynos/lille#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T18:32:30.955Z
Learning: Fixtures in rstest are regular Rust functions annotated with #[fixture]; their return values are injected into tests by matching argument names, promoting separation of setup and test logic.

Learnt from: CR
PR: leynos/mxd#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T23:40:48.640Z
Learning: Fixtures in rstest are regular Rust functions annotated with #[fixture]; their return values are injected into test functions by matching argument names, promoting test readability and reusability.

Learnt from: CR
PR: leynos/mxd#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T23:40:09.111Z
Learning: rstest supports composing fixtures by allowing fixtures to depend on other fixtures via function arguments, enabling modular and reusable test setups.

Learnt from: CR
PR: leynos/mxd#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T23:40:48.640Z
Learning: rstest supports composing fixtures by allowing fixtures to depend on other fixtures via function arguments, enabling modular and maintainable test setups.

Learnt from: CR
PR: leynos/netsuke#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-18T19:05:14.471Z
Learning: Use rstest for tests with complex setups, parameterization, or when aiming for improved readability and reduced boilerplate.

Learnt from: CR
PR: leynos/mdtablefix#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-20T03:27:35.813Z
Learning: Use rstest for tests with complex setups, parameterization, or when aiming for improved readability and reduced boilerplate.

Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T00:05:36.857Z
Learning: Fixtures in rstest are Rust functions annotated with #[fixture] that provide setup data or resources for tests. They can return any valid Rust type and can depend on other fixtures by listing them as arguments.

Learnt from: CR
PR: leynos/mxd#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T23:40:09.111Z
Learning: Fixtures in rstest are Rust functions annotated with #[fixture] that encapsulate setup logic and can return any valid Rust type, including primitives, structs, or trait objects.

Learnt from: CR
PR: leynos/mxd#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T23:40:09.111Z
Learning: rstest injects fixtures into test functions by matching argument names to fixture function names, following Rust's standard name resolution rules.

Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T00:05:36.857Z
Learning: rstest resolves fixture injection by matching argument names in the test function to fixture function names, following Rust's standard name resolution rules. Careful naming is required to avoid ambiguity.

Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T00:05:36.857Z
Learning: By default, rstest creates a new instance of a fixture for each test that uses it, ensuring test isolation and preventing shared mutable state between tests.

Learnt from: CR
PR: leynos/lille#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T18:32:30.955Z
Learning: By default, rstest creates a new instance of each fixture for every test that uses it, ensuring test isolation and preventing shared mutable state between tests.

Learnt from: CR
PR: leynos/mdtablefix#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T23:09:41.600Z
Learning: By default, rstest creates a new instance of each fixture for every test that uses it, ensuring test isolation and preventing shared mutable state between tests.

Learnt from: CR
PR: leynos/lille#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T18:32:30.955Z
Learning: Parameterized tests in rstest use #[case(...)] for table-driven scenarios (each case generates a separate test) and #[values(...)] for combinatorial testing (generating the Cartesian product of values for arguments).

Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T00:05:37.557Z
Learning: Parameterized tests in rstest use #[case(...)] for table-driven scenarios (specific input/output pairs) and #[values(...)] for combinatorial testing (Cartesian product of argument values), generating individual test cases for each combination.

Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T00:05:36.857Z
Learning: Parameterized tests in rstest are created using #[case(...)] for table-driven scenarios and #[values(...)] for combinatorial testing, generating individual test cases for each set or combination of inputs.

Learnt from: CR
PR: leynos/mxd#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T23:40:48.640Z
Learning: Parameterized tests in rstest use #[case(...)] for table-driven scenarios and #[values(...)] for combinatorial (Cartesian product) testing, generating individual test cases for each combination.

Learnt from: CR
PR: leynos/mxd#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T23:40:09.111Z
Learning: Parameterized tests in rstest use #[case(...)] for table-driven scenarios and #[values(...)] for combinatorial (Cartesian product) testing, generating individual test cases for each combination.

Learnt from: CR
PR: leynos/mdtablefix#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T23:09:41.600Z
Learning: The #[case(...)] attribute in rstest allows table-driven tests by generating a separate test for each set of input arguments, with each case reported individually by the test runner.

Learnt from: CR
PR: leynos/netsuke#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-18T19:05:14.471Z
Learning: Applies to docs/**/*.rs : Use the #[case(...)] attribute to define table-driven parameterized tests in Rust with rstest.

Learnt from: CR
PR: leynos/mdtablefix#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T23:09:41.600Z
Learning: Fixtures and parameterized arguments (#[case], #[values]) can be combined in the same rstest test function, allowing for expressive and flexible test scenarios.

Learnt from: CR
PR: leynos/wireframe#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-21T13:27:57.996Z
Learning: Applies to docs/**/*.rs : Use the #[case(...)] attribute in #[rstest] tests to define table-driven, parameterized test cases.

Learnt from: CR
PR: leynos/mdtablefix#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-20T03:27:35.813Z
Learning: Applies to docs/**/*.rs : Use the #[case(...)] attribute to define table-driven, parameterized tests with specific input scenarios.

Learnt from: CR
PR: leynos/mdtablefix#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T23:09:41.600Z
Learning: The #[values(...)] attribute in rstest enables combinatorial testing by generating tests for every possible combination of provided values across arguments, which can lead to a combinatorial explosion if not used judiciously.

Learnt from: CR
PR: leynos/mdtablefix#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-20T03:27:35.813Z
Learning: Applies to docs/**/*.rs : Use the #[values(...)] attribute to generate combinatorial tests for all combinations of provided values.

Learnt from: CR
PR: leynos/lille#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-20T12:06:42.577Z
Learning: Applies to docs/**/*.rs : Use the #[values(...)] attribute on test function arguments to generate combinatorial (Cartesian product) parameterized tests in rstest.

Learnt from: CR
PR: leynos/wireframe#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-21T13:27:57.996Z
Learning: Applies to docs/**/*.rs : Use the #[values(...)] attribute in #[rstest] tests to generate tests for all combinations of provided values (combinatorial testing).

Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-20T17:11:39.979Z
Learning: Applies to docs/**/*.{rs} : Use #[values(...)] attributes on test function arguments to generate combinatorial (Cartesian product) parameterized tests in rstest.

Learnt from: CR
PR: leynos/ddlint#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-18T18:40:11.379Z
Learning: Applies to docs/**/*.rs : Use the #[values(...)] attribute on test function arguments to generate combinatorial test matrices.

Learnt from: CR
PR: leynos/netsuke#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-18T19:05:14.471Z
Learning: Applies to docs/**/*.rs : Use the #[values(...)] attribute on test function arguments to generate combinatorial test cases with rstest.

Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-20T17:11:39.979Z
Learning: Applies to docs/**/*.{rs} : Combine fixtures and parameterized arguments (#[case] or #[values]) in the same rstest test function for expressive test scenarios.

Learnt from: CR
PR: leynos/wireframe#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-21T13:27:57.996Z
Learning: Applies to docs/**/*.rs : Combine fixtures and parameterized arguments (#[case] or #[values]) in the same #[rstest] test function for expressive test scenarios.

Learnt from: CR
PR: leynos/lille#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-20T12:06:42.577Z
Learning: Applies to docs/**/*.rs : Combine fixtures and parameterized arguments (#[case] or #[values]) in the same rstest test function for expressive test scenarios.

Learnt from: CR
PR: leynos/netsuke#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-18T19:05:14.471Z
Learning: Applies to docs/**/*.rs : Combine fixtures and parameterized arguments (#[case] or #[values]) in the same test function for expressive test scenarios.

Learnt from: CR
PR: leynos/mdtablefix#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-20T03:27:35.813Z
Learning: Applies to docs/**/*.rs : Combine fixtures and parameterized arguments (#[case] or #[values]) in the same test function for expressive test scenarios.

Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T00:05:37.557Z
Learning: The #[from(original_fixture_name)] attribute allows renaming a fixture when injecting it into a test or another fixture, which is useful for destructuring or improving argument clarity.

Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T00:05:36.857Z
Learning: The #[from(original_fixture_name)] attribute allows renaming a fixture when injecting it into a test or another fixture, which is especially useful when destructuring or for clarity.

Learnt from: CR
PR: leynos/mdtablefix#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T23:09:41.600Z
Learning: The #[from(original_fixture_name)] attribute allows renaming a fixture when injecting it into a test or another fixture, which is useful for destructuring or clarity.

Learnt from: CR
PR: leynos/mxd#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T23:40:48.640Z
Learning: The #[from(original_fixture_name)] attribute allows renaming a fixture when injecting it into a test or another fixture, which is useful for destructuring or clarity.

Learnt from: CR
PR: leynos/lille#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T18:32:30.955Z
Learning: The #[from(original_fixture_name)] attribute allows renaming a fixture when injecting it into a test or another fixture, which is useful for destructuring or clarity.

Learnt from: CR
PR: leynos/mxd#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T23:40:09.111Z
Learning: The #[from(original_fixture_name)] attribute allows renaming a fixture when injecting it into a test or another fixture, which is useful for destructuring or clarity.

Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-20T17:11:39.979Z
Learning: Applies to docs/**/*.{rs} : Use the #[from(original_fixture_name)] attribute to rename injected fixtures in test or fixture function arguments for clarity or destructuring.

Learnt from: CR
PR: leynos/wireframe#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-21T13:27:57.996Z
Learning: Applies to docs/**/*.rs : Use the #[from(original_fixture_name)] attribute to rename injected fixture arguments in test functions or other fixtures for clarity.

Learnt from: CR
PR: leynos/lille#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-20T12:06:42.577Z
Learning: Applies to docs/**/*.rs : Use the #[from(original_fixture_name)] attribute to rename injected fixture arguments in test functions or other fixtures.

Learnt from: CR
PR: leynos/ddlint#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-18T18:40:11.379Z
Learning: Applies to docs/**/*.rs : Use the #[from(original_fixture_name)] attribute to rename injected fixture arguments in test functions.

Learnt from: CR
PR: leynos/mxd#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T23:40:09.111Z
Learning: The #[default(...)] attribute in fixture arguments provides default values, and #[with(...)] in tests overrides these defaults for specific test cases, enabling flexible and DRY fixture configuration.

Learnt from: CR
PR: leynos/mdtablefix#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T23:09:41.600Z
Learning: The #[default(...)] attribute provides default values for fixture arguments, and #[with(...)] can override these defaults in specific tests, enabling highly configurable fixtures.

Learnt from: CR
PR: leynos/lille#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T18:32:30.955Z
Learning: The #[default(...)] attribute provides default values for fixture arguments, and #[with(...)] on test arguments overrides these defaults for specific tests, enabling flexible and DRY fixture configurations.

Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T00:05:36.857Z
Learning: Fixtures can be made configurable using #[default(...)] for fixture arguments and #[with(...)] in tests to override defaults, enabling flexible and DRY test setups.

Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T00:05:36.857Z
Learning: Asynchronous fixtures and tests are supported by defining async fn fixtures and test functions. rstest integrates with async runtimes like async-std or tokio by combining #[rstest] with the runtime's test attribute.

Learnt from: CR
PR: leynos/mdtablefix#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T23:09:41.600Z
Learning: rstest supports asynchronous fixtures and tests by allowing async fn for both, and integrates with async runtimes like async-std or tokio by combining #[rstest] with the runtime's #[test] attribute.

Learnt from: CR
PR: leynos/mxd#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T23:40:09.111Z
Learning: rstest supports async fixtures and async test functions; it integrates with async runtimes like async-std or tokio by using the appropriate test attribute (e.g., #[tokio::test]) alongside #[rstest].

Learnt from: CR
PR: leynos/mxd#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T23:40:48.640Z
Learning: rstest supports async fixtures and async test functions; it integrates with async runtimes like async-std or tokio by combining #[rstest] with the appropriate runtime's #[test] attribute.

Learnt from: CR
PR: leynos/lille#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T18:32:30.955Z
Learning: rstest supports async fixtures and async test functions; it integrates with async runtimes like async-std or tokio by combining #[rstest] with the runtime's #[test] attribute.

Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T00:05:37.557Z
Learning: rstest supports asynchronous testing by allowing async fn fixtures and async test functions, integrating with async runtimes like async-std or tokio via their respective #[async_std::test] or #[tokio::test] attributes.

Learnt from: CR
PR: leynos/mdtablefix#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-20T03:27:35.813Z
Learning: Applies to docs/**/*.rs : Define asynchronous fixtures as async fn and use them in async tests with #[rstest].

Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-20T17:11:39.979Z
Learning: Applies to docs/**/*.{rs} : Define asynchronous fixtures as async fn with #[fixture] and use them in async rstest tests.

Learnt from: CR
PR: leynos/ddlint#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-18T18:40:11.379Z
Learning: Applies to docs/**/*.rs : Write asynchronous tests as async fn functions annotated with #[rstest] and the appropriate async runtime attribute (e.g., #[tokio::test], #[async_std::test]).

Learnt from: CR
PR: leynos/netsuke#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-18T19:05:14.471Z
Learning: Applies to docs/**/*.rs : Annotate asynchronous test functions with both #[rstest] and the appropriate async runtime attribute (e.g., #[tokio::test], #[async_std::test]).

Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-20T17:11:39.979Z
Learning: Applies to docs/**/*.{rs} : Annotate async test functions with both #[rstest] and the appropriate async runtime attribute (e.g., #[tokio::test], #[async_std::test]).

Learnt from: CR
PR: leynos/wireframe#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-21T13:27:57.996Z
Learning: Applies to docs/**/*.rs : Annotate async test functions with both #[rstest] and the appropriate async runtime test attribute (e.g., #[tokio::test], #[async_std::test]).

Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T00:05:36.857Z
Learning: The #[future] and #[awt] attributes in rstest simplify working with async fixtures and arguments by removing the need for explicit impl Future types and automating .await calls.

Learnt from: CR
PR: leynos/mxd#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T23:40:09.111Z
Learning: The #[future] and #[awt] attributes in rstest simplify working with async fixtures and arguments by removing boilerplate and optionally auto-awaiting futures.

Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T00:05:37.557Z
Learning: The #[future] and #[awt] attributes in rstest simplify working with async fixtures and arguments by removing boilerplate and optionally auto-awaiting futures.

Learnt from: CR
PR: leynos/mdtablefix#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T23:09:41.600Z
Learning: The #[future] and #[awt] attributes in rstest simplify working with async fixtures and arguments by removing boilerplate and optionally auto-awaiting futures.

Learnt from: CR
PR: leynos/lille#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T18:32:30.955Z
Learning: The #[future] and #[awt] attributes in rstest simplify working with async fixtures and arguments by removing boilerplate and optionally auto-awaiting futures.

Learnt from: CR
PR: leynos/mxd#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T23:40:48.640Z
Learning: The #[future] and #[awt] attributes in rstest simplify working with async fixtures and arguments by removing boilerplate and optionally auto-awaiting futures.

Learnt from: CR
PR: leynos/lille#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-20T12:06:42.577Z
Learning: Applies to docs/**/*.rs : Use the #[future] attribute on async fixture or argument types to simplify their usage in rstest tests, and #[awt] to automatically await them.

Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-20T17:11:39.979Z
Learning: Applies to docs/**/*.{rs} : Encapsulate mock setup logic for external services (e.g., databases, HTTP APIs) within rstest fixtures to isolate tests from real dependencies.

Learnt from: CR
PR: leynos/lille#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-20T12:06:42.577Z
Learning: Applies to docs/**/*.rs : Encapsulate mock object setup for external services (e.g., databases, HTTP APIs) within rstest fixtures to isolate tests from real dependencies.

Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T00:05:37.557Z
Learning: Mocking external services (e.g., databases, HTTP APIs) is best encapsulated in fixtures, allowing tests to receive pre-configured mock objects and keeping test logic focused and isolated.

Learnt from: CR
PR: leynos/mxd#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T23:40:09.111Z
Learning: Mocking external services (e.g., databases, HTTP APIs) is best encapsulated in fixtures, allowing tests to request pre-configured mock objects as dependencies.

Learnt from: CR
PR: leynos/mdtablefix#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T23:09:41.600Z
Learning: Mocking external services (e.g., databases, HTTP APIs) is best encapsulated in fixtures, allowing tests to request pre-configured mocks as arguments and keeping test logic focused.

Learnt from: CR
PR: leynos/mxd#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T23:40:09.111Z
Learning: The #[files("glob_pattern")] attribute in rstest parameterizes tests over files matching a glob, injecting either their PathBuf or contents (as &str or &[u8]) into test arguments.

Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T00:05:36.858Z
Learning: The #[files("glob_pattern")] attribute parameterizes tests over files matching a glob, injecting either PathBufs or file contents (with mode = "str" or "bytes") as arguments, enabling data-driven testing from the filesystem.

Learnt from: CR
PR: leynos/wireframe#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-21T13:27:57.996Z
Learning: Applies to docs/**/*.rs : Use the #[files("glob_pattern")] attribute in #[rstest] tests to inject file paths or contents matching a glob pattern as test arguments.

Learnt from: CR
PR: leynos/lille#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-20T12:06:42.577Z
Learning: Applies to docs/**/*.rs : Use the #[files("glob_pattern")] attribute in rstest to parameterize tests over files matching a glob pattern, injecting file paths or contents as arguments.

Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T00:05:37.557Z
Learning: The #[files("glob_pattern")] attribute parameterizes tests over files matching a glob, injecting either PathBufs or file contents (as &str or &[u8]) into test arguments, and is useful for data-driven testing.

Learnt from: CR
PR: leynos/mxd#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T23:40:48.640Z
Learning: The #[files("glob_pattern")] attribute in rstest can parameterize tests over files matching a glob, injecting either file paths or file contents as test arguments.

Learnt from: CR
PR: leynos/lille#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T18:32:30.955Z
Learning: The #[files("glob_pattern")] attribute parameterizes tests over files matching a glob, injecting either their PathBuf or contents (as &str or &[u8]) into test arguments.

Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-20T17:11:39.979Z
Learning: Applies to docs/**/*.{rs} : Use the #[files("glob_pattern")] attribute on test arguments to inject file paths or contents matching the specified glob pattern for data-driven tests.

Learnt from: CR
PR: leynos/ddlint#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-18T18:40:11.379Z
Learning: Applies to docs/**/*.rs : Use the #[files("glob_pattern")] attribute to inject file paths or contents as test arguments for data-driven tests.

Learnt from: CR
PR: leynos/mdtablefix#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-20T03:27:35.813Z
Learning: Applies to docs/**/*.rs : Use the #[files("glob_pattern")] attribute to inject file paths or contents as test arguments for data-driven tests.

Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T00:05:37.557Z
Learning: The rstest_reuse crate enables DRY parameterization by allowing reusable test templates with #[template] and #[apply(template_name)], reducing duplication of #[case] or #[values] attributes across multiple tests.

Learnt from: CR
PR: leynos/mxd#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T23:40:09.111Z
Learning: The rstest_reuse crate enables DRY test case definitions by allowing reusable templates of #[case] or #[values] attributes, which can be applied to multiple test functions.

Learnt from: CR
PR: leynos/mxd#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T23:40:48.640Z
Learning: The rstest_reuse crate enables DRY test case definitions by allowing reusable templates of #[case] or #[values] attributes, which can be applied to multiple test functions.

Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T00:05:36.858Z
Learning: The rstest_reuse crate allows defining reusable test templates with #[template] and applying them to multiple test functions with #[apply(template_name)], promoting DRY principles in parameterized test definitions.

Learnt from: CR
PR: leynos/mdtablefix#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T23:09:41.600Z
Learning: The rstest_reuse crate allows defining reusable test templates with #[template] and applying them to multiple test functions with #[apply(template_name)], promoting DRY principles in parameterized testing.

Learnt from: CR
PR: leynos/lille#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T18:32:30.955Z
Learning: The rstest_reuse crate allows defining reusable test templates with #[template] and applying them to multiple test functions with #[apply], promoting DRY parameterization.

Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-20T17:11:39.979Z
Learning: Applies to docs/**/*.{rs} : Use the rstest_reuse crate's #[template] and #[apply(template_name)] attributes to define and reuse common sets of test cases across multiple rstest functions.

Learnt from: CR
PR: leynos/wireframe#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-21T13:27:57.996Z
Learning: Applies to docs/**/*.rs : Use the rstest_reuse crate's #[template] and #[apply(template_name)] attributes to define and apply reusable test case templates, avoiding duplication.

Learnt from: CR
PR: leynos/lille#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-20T12:06:42.577Z
Learning: Applies to docs/**/*.rs : Define reusable test templates with the #[template] attribute and apply them to test functions using #[apply(template_name)] via the rstest_reuse crate.

Learnt from: CR
PR: leynos/ddlint#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-18T18:40:11.379Z
Learning: Applies to docs/**/*.rs : Define reusable test templates with #[template] and apply them to test functions with #[apply(template_name)] using the rstest_reuse crate.

Learnt from: CR
PR: leynos/mdtablefix#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T23:09:41.600Z
Learning: Best practices for organizing fixtures and tests include: placing module-specific fixtures in the module's tests submodule, sharing fixtures via common modules or #[cfg(test)] in the library, using descriptive names, composing small fixtures, and grouping related tests and fixtures into modules.

Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-20T17:11:39.979Z
Learning: Organize fixtures and tests by grouping related fixtures in modules, using clear naming conventions, and placing shared fixtures in common modules or under #[cfg(test)] as appropriate.

Learnt from: CR
PR: leynos/lille#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-20T12:06:42.577Z
Learning: Organize fixtures and tests by grouping related fixtures in modules, using clear naming conventions, and placing shared fixtures in common modules or under #[cfg(test)].

Learnt from: CR
PR: leynos/wireframe#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-21T13:27:57.996Z
Learning: Organize fixtures and tests by grouping related items into modules, using clear naming conventions, and placing shared fixtures in common modules or under #[cfg(test)].

Learnt from: CR
PR: leynos/ddlint#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-18T18:40:11.379Z
Learning: Organize fixtures and tests by grouping related items into modules, using clear naming conventions, and placing shared fixtures in common modules or under #[cfg(test)].

Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T00:05:36.858Z
Learning: Organize fixtures and tests by grouping related items into modules, using clear naming conventions, and keeping fixtures focused on single responsibilities. Use #[once] only for expensive, read-only, and safely static resources.

Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T00:05:37.557Z
Learning: Best practices for organizing rstest-based tests include grouping related fixtures and tests into modules, using descriptive names, composing small focused fixtures, and preferring per-test fixtures for proper resource management.

Learnt from: CR
PR: leynos/lille#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T18:32:30.955Z
Learning: rstest is most beneficial for complex setups, parameterized testing, and when aiming for readable, DRY, and maintainable test suites; for trivial tests, standard #[test] may suffice.

Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T00:05:37.557Z
Learning: rstest is most beneficial for complex setups, parameterized testing, and when aiming for readable, DRY, and maintainable test suites; for simple unit tests, standard #[test] may suffice.

Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-20T17:11:39.979Z
Learning: Use rstest for tests requiring complex setup, parameterization, or improved readability, but consider standard #[test] for simple, non-parameterized unit tests.

Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T00:05:36.858Z
Learning: rstest-generated parameterized tests are named with a ::case_N suffix, aiding in identifying and running specific failing cases. Understanding this naming helps with debugging and selective test execution.

Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T00:05:37.557Z
Learning: rstest-generated parameterized tests are named with a convention like test_function_name::case_N, aiding in identifying and running specific failing cases.

Learnt from: CR
PR: leynos/mdtablefix#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T23:09:41.600Z
Learning: The rstest-log crate can be used to ensure proper logging initialization in rstest tests, and the test-with crate can be combined with rstest to conditionally execute tests based on runtime conditions.

🧬 Code Graph Analysis (1)

rust_extension/tests/test_utils/shared_buffer.rs (1)

rust_extension/tests/stream_handler_tests.rs (2)

• write (25-27)
• flush (29-33)

🪛 LanguageTool

docs/rust-testing-with-rstest-fixtures.md

[style] ~305-~305: Consider using the typographical ellipsis character here instead.
Context: ... into something conceptually similar to #[test] fn the_test() { let injected = injected_fixture_func(); /*... */ } within the test body, implying a ...

(ELLIPSIS)

---

[uncategorized] ~591-~591: Use ‘wants’ only when referring to the third person singular such as “he wants”.
Context: ...the test only cares about some parts or wants to use more idiomatic names for destruc...

(CONFUSION_BETWEEN_NNS_OR_WANTS_TO)

---

[grammar] ~694-~694: Please add a punctuation mark at the end of paragraph.
Context: ... messages. ## VI. Asynchronous Testing with rstest rstest provides robust supp...

(PUNCTUATION_PARAGRAPH_END)

---

[uncategorized] ~1023-~1023: The preposition ‘as’ seems more likely in this position.
Context: ...` attribute. This attribute can be used on a test function argument to inject file...

(AI_HYDRA_LEO_REPLACE_ON_AS)

---

[duplication] ~1235-~1235: Possible typo: you repeated a word.
Context: ...and running specific failing cases with cargo test test_function_name::case_N. Some IDEs or de...

(ENGLISH_WORD_REPEAT_RULE)

---

[style] ~1278-~1278: ‘in conjunction with’ might be wordy. Consider a shorter alternative.
Context: ...y of network services.22 It can be used in conjunction with rstest. For example, an rstest test...

(EN_WORDINESS_PREMIUM_IN_CONJUNCTION_WITH)

---

[uncategorized] ~1300-~1300: Possible missing comma found.
Context: ...f::newwhen an existing buffer must be shared orSharedBuf::default` for a fresh buf...

(AI_HYDRA_LEO_MISSING_COMMA)

---

[uncategorized] ~1302-~1302: Use a comma before ‘so’ if it connects two independent clauses (unless they are closely connected and short).
Context: ...e contents() method returns a snapshot so tests can assert output without exposin...

(COMMA_COMPOUND_SENTENCE_2)

🔇 Additional comments (7)

rust_extension/tests/test_utils/shared_buffer.rs (7)

12-20: Excellent encapsulation improvement.

The conversion from tuple struct to named-field struct with private buffer is a solid design decision. The documentation clearly explains the encapsulation rationale, preventing accidental bypassing of the Write implementation.

---

22-26: Clean constructor implementation.

The new method follows standard Rust conventions and provides a clear interface for creating SharedBuf instances.

---

28-36: Well-designed accessor method.

The contents() method provides safe snapshot access to the buffer without exposing the internal mutex. The #[allow(dead_code)] annotation is appropriate for utility methods that may be used in future tests.

---

38-44: Useful Default implementation.

The Default trait implementation provides convenient creation of SharedBuf instances for tests that don't require shared buffer state.

---

46-60: Correctly updated Write implementation.

The Write trait implementation has been properly updated to use the private buffer field while maintaining the same functionality and error handling.

---

76-118: Consistent loom module implementation.

The loom module correctly mirrors the std module changes, maintaining API consistency while properly using loom::sync types for concurrency testing. The parallel structure supports both standard and loom-based testing scenarios.

---

1-126: Exemplary refactoring that improves encapsulation.

This refactoring demonstrates excellent adherence to encapsulation principles by making the internal buffer private and providing controlled access through well-designed methods. The changes maintain API consistency between std and loom modules while improving the safety and clarity of the testing utilities.

✨ Finishing Touches

• 📝 Generate Docstrings

🧪 Generate unit tests

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch codex/encapsulate-sharedbuf-inner-implementation

---

🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

• Review comments: Directly reply to a review comment made by CodeRabbit. Example:
  • I pushed a fix in commit <commit_id>, please review it.
  • Explain this complex logic.
  • Open a follow-up GitHub issue for this discussion.
• Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
  • @coderabbitai explain this code block.
  • @coderabbitai modularize this function.
• PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
  • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
  • @coderabbitai read src/utils.ts and explain its main purpose.
  • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
  • @coderabbitai help me debug CodeRabbit configuration file.

Support

Need help? Create a ticket on our support page for assistance with any issues or questions.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

• @coderabbitai pause to pause the reviews on a PR.
• @coderabbitai resume to resume the paused reviews.
• @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
• @coderabbitai full review to do a full review from scratch and review all the files again.
• @coderabbitai summary to regenerate the summary of the PR.
• @coderabbitai generate docstrings to generate docstrings for this PR.
• @coderabbitai generate sequence diagram to generate a sequence diagram of the changes in this PR.
• @coderabbitai generate unit tests to generate unit tests for this PR.
• @coderabbitai resolve resolve all the CodeRabbit review comments.
• @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
• @coderabbitai help to get help.

Other keywords and placeholders

• Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
• Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
• Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

• You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
• Please see the configuration documentation for more information.
• If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

• Visit our Documentation for detailed information on how to use CodeRabbit.
• Join our Discord Community to get help, request features, and share feedback.
• Follow us on X/Twitter for updates and announcements.

[sourcery-ai]

Hey @leynos - I've reviewed your changes - here's some feedback:

• Consider adding a convenience Default impl (or a SharedBuf::default()) that initializes its own Arc<Mutex<Vec>> so tests don’t have to repeatedly construct the Arc and Mutex boilerplate.
• Returning the raw Arc<Mutex<Vec>> via buffer() still exposes the inner buffer—consider providing a snapshot accessor (e.g. fn contents(&self) -> Vec<u8>) to preserve encapsulation and avoid misuse.

Prompt for AI Agents

Please address the comments from this code review:
## Overall Comments
- Consider adding a convenience Default impl (or a `SharedBuf::default()`) that initializes its own Arc<Mutex<Vec<u8>>> so tests don’t have to repeatedly construct the Arc and Mutex boilerplate.
- Returning the raw Arc<Mutex<Vec<u8>>> via `buffer()` still exposes the inner buffer—consider providing a snapshot accessor (e.g. `fn contents(&self) -> Vec<u8>`) to preserve encapsulation and avoid misuse.

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[leynos]

@sourcery-ai review

[sourcery-ai]

Hey @leynos - I've reviewed your changes and they look great!

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}