Conversation
Reviewer's GuideThis PR introduces a clap-based CLI skeleton with global options and subcommands, configures production and test dependencies in Cargo.toml, implements both unit and cucumber-driven integration tests for the CLI, and updates related documentation and linting configuration. Class diagram for the new CLI structureclassDiagram
class Cli {
+PathBuf file
+Option<PathBuf> directory
+Option<usize> jobs
+Option<Commands> command
}
class Commands {
}
Cli o-- Commands
class Build {
+Vec<String> targets
}
class Clean {
}
class Graph {
}
Commands <|-- Build
Commands <|-- Clean
Commands <|-- Graph
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
Summary by CodeRabbitNew Features
Tests
Documentation
Chores
WalkthroughIntroduce a comprehensive command-line interface (CLI) for the Netsuke tool using the Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant CLI as Netsuke CLI (main.rs)
User->>CLI: Run `netsuke [OPTIONS] [COMMAND]`
CLI->>CLI: Parse args with clap
alt Build command (default)
CLI->>CLI: Collect targets (if any)
CLI->>User: Print "Build command invoked" (placeholder)
else Clean command
CLI->>User: Print "Clean command invoked"
else Graph command
CLI->>User: Print "Graph command invoked"
end
Poem
✨ Finishing Touches
🧪 Generate unit tests
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed 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)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
There was a problem hiding this comment.
Hey @leynos - I've reviewed your changes and found some issues that need to be addressed.
- Consider using clap’s
default_subcommandattribute so you don’t have to manually unwrap and fallback to Build in main. - Extract the argument parsing and command dispatch logic into a separate function or module to make the CLI behavior easier to test and maintain.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- Consider using clap’s `default_subcommand` attribute so you don’t have to manually unwrap and fallback to Build in main.
- Extract the argument parsing and command dispatch logic into a separate function or module to make the CLI behavior easier to test and maintain.Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
|
Stale |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🔭 Outside diff range comments (1)
tests/cucumber.rs (1)
1-44: Add module-level documentation as required by coding guidelines.The file is missing the required module-level documentation comment explaining the module's purpose and utility. Add this to comply with the coding guidelines.
+//! Cucumber behavioral tests for the netsuke CLI application. +//! +//! This module defines step definitions and test world for testing CLI behaviour +//! using the Cucumber framework. Tests verify command-line argument parsing, +//! help output, and process exit statuses. + use assert_cmd::Command;
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
⛔ Files ignored due to path filters (1)
Cargo.lockis excluded by!**/*.lock
📒 Files selected for processing (12)
.markdownlint-cli2.jsonc(1 hunks)AGENTS.md(1 hunks)Cargo.toml(2 hunks)docs/behavioural-testing-in-rust-with-cucumber.md(18 hunks)docs/netsuke-design.md(2 hunks)docs/roadmap.md(6 hunks)docs/rust-testing-with-rstest-fixtures.md(27 hunks)docs/snapshot-testing-in-netsuke-using-insta.md(7 hunks)src/main.rs(1 hunks)tests/cli.rs(1 hunks)tests/cucumber.rs(1 hunks)tests/features/cli_help.feature(1 hunks)
🧰 Additional context used
📓 Path-based instructions (5)
**/*.md
Instructions used from:
Sources:
📄 CodeRabbit Inference Engine
- AGENTS.md
⚙️ CodeRabbit Configuration File
docs/**/*.md
Instructions used from:
Sources:
📄 CodeRabbit Inference Engine
- AGENTS.md
**/*.rs
Instructions used from:
Sources:
📄 CodeRabbit Inference Engine
- AGENTS.md
⚙️ CodeRabbit Configuration File
tests/**/*.rs
Instructions used from:
Sources:
📄 CodeRabbit Inference Engine
- AGENTS.md
Cargo.toml
Instructions used from:
Sources:
📄 CodeRabbit Inference Engine
- AGENTS.md
🧠 Learnings (4)
AGENTS.md (2)
Learnt from: CR
PR: leynos/mxd#0
File: AGENTS.md:0-0
Timestamp: 2025-06-25T23:37:47.576Z
Learning: For Rust projects: run 'cargo fmt --all', 'cargo clippy -- -D warnings', and 'make test' before committing; fix warnings in code, not by silencing them.
Learnt from: CR
PR: leynos/femtologging#0
File: AGENTS.md:0-0
Timestamp: 2025-06-25T00:03:53.874Z
Learning: For Rust: Run cargo fmt, cargo clippy -- -D warnings, and cargo test before committing; clippy warnings must be disallowed.
docs/rust-testing-with-rstest-fixtures.md (107)
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-26T00:20:29.033Z
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, improving readability and reducing boilerplate.
Learnt from: CR
PR: leynos/femtologging#0
File: docs/contents.md:0-0
Timestamp: 2025-06-27T10:16:24.190Z
Learning: Use the `rstest` crate in Rust to implement fixture-based testing, which can improve test modularity and reusability.
Learnt from: CR
PR: leynos/ddlint#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-28T15:32:52.327Z
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/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/mdtablefix#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T23:09:41.600Z
Learning: The procedural macro approach of rstest can increase compile times and may require understanding macro expansion for debugging complex 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: Procedural macros in rstest can increase compile times and may complicate debugging, but they provide strong compile-time validation of test structure and types.
Learnt from: CR
PR: leynos/lille#0
File: docs/testing-declarative-game-logic-in-dbsp.md:0-0
Timestamp: 2025-07-07T22:05:39.651Z
Learning: Applies to docs/{tests/**/*.{rs},**/*_test.rs} : Use the rstest crate to create reusable, composable test setups (fixtures) for both unit and BDD 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: 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/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/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-26T00:20:29.033Z
Learning: Fixtures in rstest are regular Rust functions annotated with #[fixture] and can return any valid Rust type, including primitives, structs, or trait objects. Fixtures can also 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: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: 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/ddlint#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-28T15:32:52.327Z
Learning: Fixtures in rstest are regular Rust functions annotated with #[fixture]; their return values are injected into tests by matching argument names, and they can return any valid Rust type, including complex structs or trait objects.
Learnt from: CR
PR: leynos/wireframe#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-30T23:08:10.890Z
Learning: Applies to docs/**/*.rs : Define fixtures in Rust by annotating functions with `#[fixture]` from the `rstest` crate.
Learnt from: CR
PR: leynos/lille#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-07T22:05:30.492Z
Learning: Applies to docs/**/*.rs : Define fixtures for test setup by annotating Rust functions with `#[fixture]` from the rstest crate.
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-26T00:20:29.033Z
Learning: rstest resolves fixture injection by argument name in the test function signature, following Rust's standard name resolution rules. Careful naming is required to avoid ambiguity when multiple fixtures with the same name are in scope.
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/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: 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/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-26T00:20:29.033Z
Learning: By default, rstest creates a new instance of a fixture for each test that uses it, ensuring test isolation and preventing state leakage between 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: By default, rstest creates a new instance of each fixture for every test that uses it, ensuring test isolation and preventing state leakage between tests.
Learnt from: CR
PR: leynos/ddlint#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-28T15:32:52.327Z
Learning: By default, rstest creates a fresh instance of each fixture for every test that uses it, ensuring test isolation and preventing state leakage between tests.
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/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-26T00:20:29.033Z
Learning: The #[case(...)] attribute in rstest enables table-driven tests by generating a separate test for each case, with clear reporting for individual failures.
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/ddlint#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-28T15:32:52.327Z
Learning: Parameterized tests in rstest use #[case(...)] for table-driven scenarios (specific input/output pairs) and #[values(...)] for combinatorial testing (Cartesian product of values), 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/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/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/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/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-26T00:20:29.033Z
Learning: Fixtures and parameterized arguments (#[case], #[values]) can be combined in the same rstest test function, allowing for expressive and comprehensive test 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: 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/mdtablefix#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-13T13:01:23.074Z
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-06-30T23:08:10.890Z
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/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/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-26T00:20:29.033Z
Learning: Use #[once] fixtures sparingly and only for expensive, read-only, and safely static resources, as their values are never dropped and may cause resource leaks if used for temporary or cleanup-requiring 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: The #[once] attribute on a fixture causes it to be initialized only once and shared across all tests, but the returned value is promoted to 'static' lifetime and is never dropped, making it suitable only for passive or OS-managed resources.
Learnt from: CR
PR: leynos/ddlint#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-28T15:32:52.327Z
Learning: Use #[once] fixtures only for expensive, read-only, and safely static resources, as they are never dropped and can lead to resource leaks if misused.
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 #[once] attribute on a fixture causes it to be initialized only once and shared across all tests, but the returned value is never dropped (static lifetime), making it suitable only for passive or OS-managed resources.
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: Use #[once] fixtures only for expensive, read-only, and safely static resources, as they are never dropped and can lead to resource leaks if misused.
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: Prefer regular (per-test) fixtures for resources that require cleanup or test isolation; use #[once] only for expensive, read-only, and truly static resources.
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-26T00:20:29.033Z
Learning: The #[once] attribute on a fixture causes it to be initialized only once and shared across all tests, but the returned value is never dropped, making it suitable only for static, read-only resources.
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 #[once] attribute on a fixture causes it to be initialized only once and shared as a static reference across all tests, but such fixtures are never dropped and cannot be async or generic.
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 #[once] attribute on a fixture causes it to be initialized only once and shared as a static reference across all tests, but such fixtures are never dropped and cannot be async or generic.
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 #[once] attribute on a fixture causes it to be initialized only once and shared as a static reference across all tests, but such fixtures are never dropped and cannot be async or generic.
Learnt from: CR
PR: leynos/ddlint#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-28T15:32:52.327Z
Learning: The #[once] attribute on a fixture causes it to be initialized only once and shared as a static reference across all tests, but such fixtures are never dropped and cannot be async or generic.
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 #[once] attribute on a fixture causes it to be initialized only once and shared as a static reference across all tests, but such fixtures are never dropped and cannot be async or generic.
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-07-13T13:01:23.074Z
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/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/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/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/ddlint#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-28T15:32:52.327Z
Learning: rstest supports asynchronous tests and fixtures: async fn fixtures and tests are supported, and integration with async runtimes (e.g., async-std, tokio) is achieved by stacking the appropriate test attribute with #[rstest].
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-26T00:20:29.033Z
Learning: rstest supports asynchronous fixtures and tests by allowing async fn for both, and integrates with async runtimes like async-std or tokio by stacking the appropriate test attribute macro.
Learnt from: CR
PR: leynos/lille#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-07T22:05:30.492Z
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/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T00:05:37.557Z
Learning: The order of procedural macro attributes (e.g., #[rstest] and #[tokio::test]) can matter for correct async test execution; ensure the async runtime's test macro is correctly placed.
Learnt from: CR
PR: leynos/ddlint#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-28T15:32:52.327Z
Learning: The order of procedural macro attributes (e.g., #[rstest], #[tokio::test]) can matter for async tests; ensure the async runtime's test macro is correctly placed to provide the execution context.
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-26T00:20:29.033Z
Learning: The order of procedural macro attributes matters when stacking rstest with async runtime macros or conditional test execution macros (e.g., test-with); rstest should typically be applied first to generate the test cases.
Learnt from: CR
PR: leynos/wireframe#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-30T23:08:10.890Z
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/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T00:05:36.858Z
Learning: The #[timeout(...)] attribute sets a maximum execution time for async tests, preventing hangs from long-running or stalled operations. A global timeout can be set via the RSTEST_TIMEOUT environment variable.
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 #[timeout(...)] attribute sets a maximum execution time for async tests, preventing hangs from long-running operations; a global timeout can be set with the RSTEST_TIMEOUT environment variable.
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-26T00:20:29.033Z
Learning: The #[timeout(...)] attribute in rstest sets a maximum execution time for async tests, preventing hangs from long-running or stalled operations. The RSTEST_TIMEOUT environment variable can set a default timeout for all async 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: The #[timeout(...)] attribute sets a maximum execution time for async tests, preventing hangs; a global timeout can be set via the RSTEST_TIMEOUT environment variable.
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 #[timeout(...)] attribute sets a maximum execution time for async tests, and a global timeout can be set via the RSTEST_TIMEOUT environment variable.
Learnt from: CR
PR: leynos/ddlint#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-28T15:32:52.327Z
Learning: The #[timeout(...)] attribute can be used to set a maximum execution time for async tests, and a global timeout can be set via the RSTEST_TIMEOUT environment variable.
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 #[timeout(...)] attribute in rstest sets a maximum execution time for async tests, and a global timeout can be set via the RSTEST_TIMEOUT environment variable.
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 #[timeout(...)] attribute (and RSTEST_TIMEOUT environment variable) can be used to set a maximum execution time for async tests, preventing hangs.
Learnt from: CR
PR: leynos/mdtablefix#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-13T13:01:23.074Z
Learning: Applies to docs/**/*.rs : Set timeouts for async tests using the `#[timeout(...)]` attribute or the `RSTEST_TIMEOUT` environment variable.
Learnt from: CR
PR: leynos/wireframe#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-30T23:08:10.890Z
Learning: Applies to docs/**/*.rs : Apply the `#[timeout(...)]` attribute to async tests to set a maximum execution time and prevent hanging tests.
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-26T00:20:29.033Z
Learning: Mocking external services (e.g., databases, HTTP APIs) is best encapsulated in fixtures, using crates like mockall or hand-rolled mocks, to keep test logic focused and maintainable.
Learnt from: CR
PR: leynos/ddlint#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-28T15:32:52.327Z
Learning: Mocks for external services (e.g., databases, HTTP APIs) should be set up within fixtures to keep tests isolated, fast, and maintainable; crates like mockall can be used for this purpose.
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/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/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: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/ddlint#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-28T15:32:52.327Z
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 test arguments, enabling data-driven testing from the filesystem.
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/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-06-26T00:20:29.033Z
Learning: The #[files("glob_pattern")] attribute in rstest parameterizes tests over files matching the pattern, injecting either PathBufs or file contents (with mode = "str" or "bytes"). This is powerful for data-driven testing but can increase binary size if embedding large files.
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/mdtablefix#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T23:09:41.600Z
Learning: The #[files("glob_pattern")] attribute parameterizes tests over files matching a glob pattern, injecting either file paths or contents, and supports modes like str or bytes for content injection.
Learnt from: CR
PR: leynos/lille#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-07T22:05:30.492Z
Learning: Applies to docs/**/*.rs : Use the `#[files("glob_pattern")]` attribute on test arguments to inject file paths or contents matching a glob pattern for data-driven tests.
Learnt from: CR
PR: leynos/mdtablefix#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-13T13:01:23.074Z
Learning: Applies to docs/**/*.rs : Use the `#[files("glob_pattern")]` attribute to inject file paths or contents into test arguments for data-driven tests.
Learnt from: CR
PR: leynos/ddlint#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-28T15:32:52.327Z
Learning: For small, simple unit tests with no shared setup or parameterization, standard #[test] may suffice; rstest is most beneficial for complex setups, parameterized testing, and DRY test code.
Learnt from: CR
PR: leynos/lille#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-07T22:05:30.492Z
Learning: Use `rstest` for tests with complex setup, parameterization, or where improved readability and reduced boilerplate are desired; for simple unit tests, standard `#[test]` may suffice.
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/wireframe#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-30T23:08:10.890Z
Learning: Prefer `rstest` for tests requiring complex setup, parameterization, or improved readability, and use standard `#[test]` for simple unit 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: The test-with crate can be combined with rstest to conditionally execute tests based on runtime conditions; macro order matters, with rstest generating test cases before test-with applies its logic.
Learnt from: CR
PR: leynos/ddlint#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-28T15:32:52.327Z
Learning: The test-with crate can be used with rstest to conditionally execute tests based on runtime conditions, but macro order matters: rstest should generate test cases before test-with applies its logic.
Learnt from: CR
PR: leynos/wireframe#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-30T23:08:10.890Z
Learning: Applies to docs/**/*.rs : Use the `test-with` crate to conditionally execute tests based on runtime conditions, applying its attributes after `#[rstest]`.
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: Conditional test execution (e.g., based on environment variables or file existence) can be achieved by combining rstest with the test-with crate, applying its attributes after rstest's macro expansion.
Learnt from: CR
PR: leynos/mdtablefix#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-13T13:01:23.074Z
Learning: Applies to docs/**/*.rs : Use the `test-with` crate for conditional test execution in conjunction with `rstest`, ensuring macro order is correct.
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.
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.
docs/netsuke-design.md (1)
Learnt from: CR
PR: leynos/netsuke#0
File: docs/roadmap.md:0-0
Timestamp: 2025-07-12T13:36:28.501Z
Learning: Applies to docs/src/main.rs : Implement the initial command-line interface structure using `clap` with the `derive` feature, as defined in `src/main.rs`. Focus on the default `build` command and global options like `--file`, `--directory`, and `--jobs`.
docs/snapshot-testing-in-netsuke-using-insta.md (1)
Learnt from: CR
PR: leynos/ddlint#0
File: docs/rust-parser-testing-comprehensive-guide.md:0-0
Timestamp: 2025-06-26T18:47:32.281Z
Learning: Snapshot testing with the `insta` crate is essential for parser development: it enables maintainable, readable tests for complex ASTs and error outputs, and greatly simplifies refactoring.
🧬 Code Graph Analysis (1)
tests/cucumber.rs (1)
src/main.rs (1)
main(46-57)
🪛 LanguageTool
docs/rust-testing-with-rstest-fixtures.md
[style] ~649-~649: This wording can make your sentence hard to follow. Try rephrasing for improved clarity.
Context: ... if the FromStr conversion fails (e.g., due to a malformed string), the error will typ...
(DUE_TO_BECAUSE)
[uncategorized] ~980-~980: Did you just mean “,” or “.”?
Context: ...ror&[u8]by specifying a mode, e.g.,#[files("glob_pattern", mode = "str")]. Additional attributes like #[base_dir ...
(COMMA_PERIOD)
[style] ~1145-~1145: Consider using the typographical ellipsis character here instead.
Context: ...le distinct #[test] functions. | #[case(...)] attributes on #[rstest] function. ...
(ELLIPSIS)
[style] ~1146-~1146: Consider using the typographical ellipsis character here instead.
Context: ...complex manual generation. | #[values(...)] attributes on arguments of #[rstest] ...
(ELLIPSIS)
docs/behavioural-testing-in-rust-with-cucumber.md
[grammar] ~68-~68: Please add a punctuation mark at the end of paragraph.
Context: ...t testing.5 The most common parallel is the Arrange-Act-Assert (AAA) pattern, ...
(PUNCTUATION_PARAGRAPH_END)
[typographical] ~78-~78: The word ‘When’ starts a question. Add a question mark (“?”) at the end of the sentence.
Context: ...e, pivotal action performed on the SUT. It's the event or trigger whose consequ...
(WRB_QUESTION_MARK)
[uncategorized] ~86-~86: Possible missing comma found.
Context: ...fies BDD. It is not an alien methodology but a structured, collaborative application...
(AI_HYDRA_LEO_MISSING_COMMA)
[grammar] ~116-~116: Did you mean “too false to”?
Context: ...st]] | harness | Must be set to false to allow cucumber to manage test execution...
(TOO_ADJECTIVE_TO)
[grammar] ~169-~169: Please add a punctuation mark at the end of paragraph.
Context: ...me a scenario begins, a new instance of the World is created; this instance is t...
(PUNCTUATION_PARAGRAPH_END)
[style] ~175-~175: Since ownership is already implied, this phrasing may be redundant.
Context: ...t isolation. Because each scenario gets its own private World instance, there is no r...
(PRP_OWN)
[style] ~201-~201: Consider using the typographical ellipsis character here instead.
Context: ...a custom constructor function using the #[world(init =...)] attribute.20 ### 2.4 Your First `ma...
(ELLIPSIS)
[style] ~324-~324: Consider using the typographical ellipsis character here instead.
Context: ...pressions.16 - Cucumber Expressions (expr = "..."): This is the recommended defau...
(ELLIPSIS)
[uncategorized] ~325-~325: Possible missing comma found.
Context: ...fault. They are less powerful than regex but are more readable and explicitly desi...
(AI_HYDRA_LEO_MISSING_COMMA)
[style] ~331-~331: Consider using the typographical ellipsis character here instead.
Context: ...on signature. - Regular Expressions (regex = "..."): For more complex matching nee...
(ELLIPSIS)
[style] ~332-~332: Consider using the typographical ellipsis character here instead.
Context: ...n use full regex syntax. Capture groups (...) in the regex correspond to function...
(ELLIPSIS)
[grammar] ~334-~334: Please add a punctuation mark at the end of paragraph.
Context: ...ework will still attempt to parse the captured &str into the function's argument ...
(PUNCTUATION_PARAGRAPH_END)
[style] ~343-~343: To elevate your writing, try using a synonym here.
Context: ...um to Low. Regex can become complex and hard to read. | Expressions are ...
(HARD_TO)
[grammar] ~350-~350: Please add a punctuation mark at the end of paragraph.
Context: ...assertion fails, the thread will panic, and cucumber will mark the step as faile...
(PUNCTUATION_PARAGRAPH_END)
[style] ~357-~357: Consider using the typographical ellipsis character here instead.
Context: ...(())passes, while one that returns anErr(...)` fails. This has two major benefits: ...
(ELLIPSIS)
[style] ~357-~357: Consider a different verb to strengthen your wording.
Context: ... that returns an Err(...) fails. This has two major benefits: 1. **Cleaner Code:...
(HAS_OFFERS)
[style] ~416-~416: This word has been used in one of the immediately preceding sentences. Using a synonym could make your text more interesting to read, unless the repetition is intentional.
Context: ...ing: Scenario Outline and Examples Often, you want to test the same behaviour wi...
(EN_REPEATEDWORDS_OFTEN)
[style] ~417-~417: Consider using a more concise synonym.
Context: ...ou want to test the same behaviour with a variety of different inputs and expected outputs. ...
(A_VARIETY_OF)
[style] ~455-~455: Consider a more descriptive alternative.
Context: ...ssing Structured Data with Data Tables Sometimes, a step requires a more complex data st...
(SOMETIMES_OCCASIONALLY)
[misspelling] ~461-~461: Use “an” instead of ‘a’ if the following word starts with a vowel sound, e.g. ‘an article’, ‘an hour’.
Context: ...your Rust step definition, you must add a step: &cucumber::gherkin::Step argume...
(EN_A_VS_AN)
[grammar] ~468-~468: Please add a punctuation mark at the end of paragraph.
Context: ... a single, readable table.25 This makes the Given steps more concise and focused...
(PUNCTUATION_PARAGRAPH_END)
[misspelling] ~757-~757: This word is normally spelled as one.
Context: ...test exactly one behaviour**.6 A common anti-pattern is to chain multiple actions and outcom...
(EN_COMPOUNDS_ANTI_PATTERN)
[uncategorized] ~865-~865: Loose punctuation mark.
Context: ...ple, tests/features/authentication/, tests/features/product_catalog/, etc....
(UNLIKELY_OPENING_PUNCTUATION)
[typographical] ~868-~868: Two consecutive commas
Context: ...ust module for each feature area (e.g., tests/steps/ authentication_steps.rs, tests/steps/catalog_steps.rs). This p...
(DOUBLE_PUNCTUATION)
[grammar] ~889-~889: Please add a punctuation mark at the end of paragraph.
Context: ...o run one at a time.20 However, overuse of @serial is often a sign of a poor te...
(PUNCTUATION_PARAGRAPH_END)
[uncategorized] ~899-~899: Loose punctuation mark.
Context: ...ing fixed delays ( tokio::time::sleep) to "wait" for an operation to complete....
(UNLIKELY_OPENING_PUNCTUATION)
[grammar] ~924-~924: Please add a punctuation mark at the end of paragraph.
Context: ...ose the problem.22 For example, a panic on `world.last_response.as_ref().unwrap()...
(PUNCTUATION_PARAGRAPH_END)
[typographical] ~1066-~1066: To join two clauses or introduce examples, consider using an em dash.
Context: ...work: a step-by-step guide with examples - Miro, accessed on July 14, 2025, <<h...
(DASH_RULE)
[grammar] ~1070-~1070: This phrase is duplicated. You should probably use “When Then” only once.
Context: ... 2. Is it acceptable to write a "Given When Then When Then" test in Gherkin? - Stack Overflow,...
(PHRASE_REPETITION)
[typographical] ~1079-~1079: To join two clauses or introduce examples, consider using an em dash.
Context: ...9d5e2df> 4. Gherkin Syntax in Cucumber - Tutorialspoint, accessed on July 14, 202...
(DASH_RULE)
[typographical] ~1082-~1082: To join two clauses or introduce examples, consider using an em dash.
Context: ...umber_gherkins.htm> 5. Given When Then - Martin Fowler, accessed on July 14, 2025...
(DASH_RULE)
[typographical] ~1085-~1085: Consider using an em dash in dialogues and enumerations.
Context: ...o Start Writing Gherkin Test Scenarios? - [Selleo.com](http:// Selleo.com), a...
(DASH_RULE)
[typographical] ~1089-~1089: To join two clauses or introduce examples, consider using an em dash.
Context: ...g-gherkin-test-scenarios> 7. Reference - Cucumber, accessed on July 14, 2025, <<h...
(DASH_RULE)
[uncategorized] ~1092-~1092: The adjective “Behavior-Driven” is spelled with a hyphen.
Context: ...ocs/> gherkin/reference/> 8. BDD (Behavior Driven Development) - ROBOT FRAMEWORK, accesse...
(DRIVEN_HYPHEN)
[typographical] ~1092-~1092: To join two clauses or introduce examples, consider using an em dash.
Context: ...> 8. BDD (Behavior Driven Development) - ROBOT FRAMEWORK, accessed on July 14, ...
(DASH_RULE)
[typographical] ~1095-~1095: To join two clauses or introduce examples, consider using an em dash.
Context: ...estcase_styles/bdd> 9. Given-When-Then - Wikipedia, accessed on July 14, 2025, <h...
(DASH_RULE)
[typographical] ~1098-~1098: To join two clauses or introduce examples, consider using an em dash.
Context: ...se "Given-When-Then" Acceptance Criteria - Ranorex, accessed on July 14, 2025, ...
(DASH_RULE)
[typographical] ~1105-~1105: To join two clauses or introduce examples, consider using an em dash.
Context: ...herkin-scenarios.html> 12. Introduction - Cucumber Rust Book, accessed on July 14,...
(DASH_RULE)
[typographical] ~1108-~1108: To join two clauses or introduce examples, consider using an em dash.
Context: ...main/> 13. Rust BDD tests with Cucumber - DEV Community, accessed on July 14, 2025...
(DASH_RULE)
[typographical] ~1112-~1112: Consider using an em dash in dialogues and enumerations.
Context: ...ernal test runners or dependencies. - GitHub, accessed on July 14, 2025, <<ht...
(DASH_RULE)
[typographical] ~1116-~1116: Consider using an em dash in dialogues and enumerations.
Context: ...ernal test runners or dependencies. - GitHub, accessed on July 14, 2025, <<ht...
(DASH_RULE)
[typographical] ~1119-~1119: To join two clauses or introduce examples, consider using an em dash.
Context: ... cucumber-rs/cucumber> 16. cucumber - Rust - Docs.rs, access...
(DASH_RULE)
[typographical] ~1119-~1119: To join two clauses or introduce examples, consider using an em dash.
Context: ...cumber-rs/cucumber> 16. cucumber - Rust - Docs.rs, accessed on J...
(DASH_RULE)
[typographical] ~1122-~1122: To join two clauses or introduce examples, consider using an em dash.
Context: ... 17. Cucumber testing framework for Rust - Crates.io, acces...
(DASH_RULE)
[typographical] ~1125-~1125: To join two clauses or introduce examples, consider using an em dash.
Context: ...ates.io/crates/cucumber> 18. Quickstart - Cucumber Rust Book, accessed on July 14,...
(DASH_RULE)
[typographical] ~1128-~1128: To join two clauses or introduce examples, consider using an em dash.
Context: ...t/quickstart.html> 19. Cucumber in Rust - Beginner's Tutorial - Florianrein's Blog...
(DASH_RULE)
[typographical] ~1128-~1128: To join two clauses or introduce examples, consider using an em dash.
Context: .... Cucumber in Rust - Beginner's Tutorial - Florianrein's Blog, accessed on July...
(DASH_RULE)
[typographical] ~1132-~1132: To join two clauses or introduce examples, consider using an em dash.
Context: ...ginners-> tutorial/> 20. Quickstart - Cucumber Rust Book, accessed on July 14,...
(DASH_RULE)
[typographical] ~1135-~1135: To join two clauses or introduce examples, consider using an em dash.
Context: ...Pitfalls and Troubleshooting in Cucumber - GeeksforGeeks, accessed on July 14, ...
(DASH_RULE)
[uncategorized] ~1139-~1139: Use a comma before ‘and’ if it connects two independent clauses (unless they are closely connected and short).
Context: .../> 22. How to do error handling in Rust and what are the common pitfalls? - Sta...
(COMMA_COMPOUND_SENTENCE_2)
[typographical] ~1139-~1139: Consider using an em dash in dialogues and enumerations.
Context: ... Rust and what are the common pitfalls? - Stack Overflow, accessed on July 14...
(DASH_RULE)
[typographical] ~1144-~1144: To join two clauses or introduce examples, consider using an em dash.
Context: ...e-common- pitfalls> 23. Data tables - Cucumber Rust Book, accessed on July 14,...
(DASH_RULE)
[typographical] ~1147-~1147: To join two clauses or introduce examples, consider using an em dash.
Context: ...a_tables.html> 24. Cucumber Data Tables - Tutorialspoint, accessed on July 14, 202...
(DASH_RULE)
[typographical] ~1155-~1155: To join two clauses or introduce examples, consider using an em dash.
Context: ...cient BDD Testing | by KailashPathak - Medium, accessed on July 14, 2025, <<htt...
(DASH_RULE)
[typographical] ~1159-~1159: To join two clauses or introduce examples, consider using an em dash.
Context: ...esting-b3eb1c7e9757> 27. Rust Solutions - WireMock, accessed on July 14, 2025, <<h...
(DASH_RULE)
[typographical] ~1162-~1162: To join two clauses or introduce examples, consider using an em dash.
Context: ... 28. Unit-testing a web service in Rust - Julio Merino ([jmmv.dev](http:// jmm...
(DASH_RULE)
[typographical] ~1166-~1166: To join two clauses or introduce examples, consider using an em dash.
Context: ...Best Practices for Effective BDD Testing - BrowserStack, accessed on July 14, 2...
(DASH_RULE)
[typographical] ~1170-~1170: To join two clauses or introduce examples, consider using an em dash.
Context: ...ucumber Testing and How to Overcome Them - Medium, accessed on July 14, 2025, <...
(DASH_RULE)
[typographical] ~1174-~1174: To join two clauses or introduce examples, consider using an em dash.
Context: ...-dc95fffb43c8> 31. Cucumber in cucumber - Rust - Docs.rs, access...
(DASH_RULE)
[typographical] ~1174-~1174: To join two clauses or introduce examples, consider using an em dash.
Context: ...fb43c8> 31. Cucumber in cucumber - Rust - Docs.rs, accessed on J...
(DASH_RULE)
[typographical] ~1177-~1177: To join two clauses or introduce examples, consider using an em dash.
Context: ....html> 32. CLI (command-line interface) - Cucumber Rust Book, accessed on July 14,...
(DASH_RULE)
[typographical] ~1180-~1180: To join two clauses or introduce examples, consider using an em dash.
Context: ...in/cli.html> 33. Continuous Integration - Cucumber, accessed on July 14, 2025, <ht...
(DASH_RULE)
[typographical] ~1186-~1186: To join two clauses or introduce examples, consider using an em dash.
Context: ...ing up effective CI/CD for Rust projects - a short primer - [shuttle.dev](http:...
(DASH_RULE)
[typographical] ~1186-~1186: To join two clauses or introduce examples, consider using an em dash.
Context: ...CI/CD for Rust projects - a short primer - shuttle.dev, a...
(DASH_RULE)
docs/snapshot-testing-in-netsuke-using-insta.md
[style] ~113-~113: Consider replacing this phrase with the adverb “consistently” to avoid wordiness.
Context: ...ermediate build graph. - Format the IR in a consistent way for comparison. Here we use pretty-prin...
(IN_A_X_MANNER)
[style] ~144-~144: Consider replacing this phrase with the adverb “predictably” to avoid wordiness.
Context: ...fields added), the snapshot will change in a predictable way, prompting a review. ## Writing Snapsh...
(IN_A_X_MANNER)
[formatting] ~267-~267: If the ‘because’ clause is essential to the meaning, do not use a comma before the clause.
Context: ...ed, re-run cargo test – it should pass, because the recorded snapshots now match the ou...
(COMMA_BEFORE_BECAUSE)
[style] ~350-~350: This word has been used in one of the immediately preceding sentences. Using a synonym could make your text more interesting to read, unless the repetition is intentional.
Context: ...l snapshots match, CI passes. No action needed. - If a snapshot test fails (meaning t...
(EN_REPEATEDWORDS_NEED)
[uncategorized] ~361-~361: Do not use a comma before “so” when introducing a dependent clause.
Context: ... files or diff results when tests fail, so they can be downloaded from the CI l...
(NO_COMMA_BEFORE_SO)
🔇 Additional comments (25)
AGENTS.md (1)
98-99: LGTM: Improved line wrapping for better readability.The formatting changes enhance readability whilst maintaining the original content and following the 80-column wrapping guideline for markdown files.
.markdownlint-cli2.jsonc (1)
10-17: LGTM: Targeted markdownlint overrides for documentation formatting.The file-specific overrides properly support the formatting improvements in the behavioural testing documentation whilst maintaining strict linting for other files.
tests/features/cli_help.feature (1)
1-7: LGTM: Well-structured Cucumber feature for CLI help testing.The feature file follows proper Gherkin syntax and provides essential behavioural testing for the CLI help functionality, aligning with the PR objectives.
docs/netsuke-design.md (1)
265-270: LGTM: Accurate documentation of CLI implementation.The added paragraph correctly documents the CLI implementation following the design specification, properly noting the use of clap crate and testing validation. This aligns with the coding guideline to update documentation when architectural decisions are implemented.
docs/snapshot-testing-in-netsuke-using-insta.md (3)
3-11: LGTM: Improved formatting enhances readability.The line wrapping changes improve readability whilst preserving the technical content and following the 80-column markdown formatting guidelines.
22-31: LGTM: Better paragraph structure and formatting.The formatting improvements make the documentation more accessible whilst maintaining the original technical guidance about snapshot testing setup.
48-51: LGTM: Clearer organisation of snapshot directory information.The formatting changes improve the explanation of snapshot directory structure whilst preserving the technical details.
docs/roadmap.md (1)
16-18: LGTM! CLI completion appropriately marked.The CLI structure implementation is correctly marked as complete, aligning with the new CLI implementation in
src/main.rs.tests/cli.rs (1)
1-23: Excellent use of rstest patterns for CLI testing.The implementation demonstrates proper rstest usage with parameterised tests via
#[case]annotations. The test coverage includes key CLI scenarios: default invocation, multiple targets, custom file paths, and help output validation.docs/rust-testing-with-rstest-fixtures.md (1)
1-1325: LGTM! Documentation formatting significantly improved.The editorial improvements enhance readability whilst maintaining technical accuracy. The 80-column line wrapping and consistent formatting align with the coding guidelines.
Cargo.toml (2)
7-7: LGTM! Appropriate clap dependency for CLI implementation.The clap dependency with "derive" feature correctly supports the CLI implementation in
src/main.rs.
49-59: LGTM! Comprehensive testing dependencies added.The dev-dependencies provide excellent testing infrastructure:
rstestfor parameterised testingcucumberfor behavioural testingassert_cmdandpredicatesfor CLI testingtokiofor async test supportThe cucumber test configuration correctly disables the default harness.
src/main.rs (4)
1-6: LGTM! Excellent module documentation.The module documentation clearly explains the CLI structure and default behaviour, following the coding guidelines for module-level comments.
10-28: LGTM! Well-structured CLI definition.The
Clistruct properly defines the global options with appropriate documentation, default values, and value names. The structure aligns with the design requirements.
30-44: LGTM! Clear subcommand structure.The
Commandsenum properly defines the three subcommands with clear documentation. The derive implementations forPartialEqandEqsupport testing.
46-57: Consider using expect() for better error context.The main function correctly parses arguments and dispatches commands. The placeholder println! statements are appropriate for this skeleton implementation.
Consider replacing
unwrap_orwith more explicit error handling:- let command = cli.command.unwrap_or(Commands::Build { targets: vec![] }); + let command = cli.command.unwrap_or_else(|| Commands::Build { targets: vec![] });This makes the default behaviour more explicit whilst maintaining the same functionality.
Likely an incorrect or invalid review comment.
docs/behavioural-testing-in-rust-with-cucumber.md (3)
2-2: Markdownlint disable comments are appropriately scoped.The markdownlint disable comments are specifically targeted to this file and address legitimate formatting concerns for documentation that may have longer lines, HTML elements, or unspecified code blocks. This aligns with the coding guidelines requirement to tightly scope lint suppressions.
6-37: Excellent paragraph restructuring for readability.The reflowing of paragraphs to respect the 80-column limit while maintaining readability significantly improves the document structure. The content maintains its educational value while becoming more accessible to readers and compliant with the markdown formatting guidelines.
51-61: HTML table to markdown table conversion enhances maintainability.The conversion from HTML tables to proper markdown tables improves both readability and maintainability. The table structure clearly presents the Gherkin keywords and their purposes, making the documentation more accessible whilst adhering to markdown best practices.
tests/cucumber.rs (6)
1-3: Import statements are well-organized and appropriate.The imports correctly bring in the necessary dependencies for CLI testing with Cucumber. The
assert_cmd::Commandfor running CLI commands,cucumbermacros for step definitions, andstd::process::Outputfor capturing command output are all appropriate for the testing requirements.
5-8: CliWorld struct follows proper Cucumber patterns.The
CliWorldstruct correctly derives the required traits (Debug,Default,World) and maintains minimal state with the optionalOutput. This design follows Cucumber best practices by providing test isolation through separate world instances per scenario.
13-21: CLI execution step is well-implemented with proper error handling.The
i_run_netsukefunction correctly usesassert_cmd::Commandto execute the binary with the provided argument. The use ofexpectwith descriptive messages is appropriate for test code where panics indicate test setup failures rather than business logic errors.
23-27: Success assertion is clear and appropriate.The
exits_successstep correctly verifies that the process completed successfully. The assertion is straightforward and the error message will be clear if the test fails.
29-38: Stdout verification step demonstrates excellent lint management.The
stdout_containsfunction properly handles the ownedStringparameter required by Cucumber expressions. The lint suppression is correctly scoped with a clear reason, and the implementation properly converts the output to UTF-8 and performs the assertion.
40-43: Async main function follows Cucumber patterns correctly.The
mainfunction properly sets up the async runtime and runs the Cucumber test suite against the features directory. This follows the standard pattern for Cucumber test runners in Rust.
| #[given("netsuke is built")] | ||
| fn netsuke_built(_world: &mut CliWorld) {} |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Empty step definition serves its purpose but add documentation.
The empty netsuke_built function is appropriate as a no-op step for scenarios that require the binary to be built, which is already handled by the test framework. However, add a comment explaining why this step is empty to improve maintainability.
#[given("netsuke is built")]
-fn netsuke_built(_world: &mut CliWorld) {}
+fn netsuke_built(_world: &mut CliWorld) {
+ // No-op: binary is built by test framework
+}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| #[given("netsuke is built")] | |
| fn netsuke_built(_world: &mut CliWorld) {} | |
| #[given("netsuke is built")] | |
| fn netsuke_built(_world: &mut CliWorld) { | |
| // No-op: binary is built by test framework | |
| } |
🤖 Prompt for AI Agents
In tests/cucumber.rs at lines 10 to 11, the empty step definition function
netsuke_built lacks explanation. Add a comment above the function explaining
that it is intentionally left empty as a no-op step because the binary build is
handled elsewhere by the test framework, to improve code clarity and
maintainability.
1 participant
Summary
src/main.rsCargo.tomlTesting
make lintmake testhttps://chatgpt.com/codex/tasks/task_e_68744cd96ca883228d78b0c84cf7e18a
Summary by Sourcery
Implement the initial CLI entry point using clap, configure Cargo.toml for runtime and test dependencies, update documentation, and add both unit and behavioural tests for the new commands
New Features:
Enhancements:
Documentation:
Tests: