Create workspace fixture for behavioural testing of lint exclusion

[coderabbitai]

Context

PR #109 introduces configurable exclusions for the no_std_fs_operations lint via dylint.toml configuration. Crates listed in excluded_crates should skip diagnostics during lint execution.

Testing Gap

Unit tests comprehensively cover:

• Configuration parsing and deserialisation
• Exclusion matching logic (is_excluded)
• Configuration loading with error handling

However, no behavioural/integration tests verify that excluded crates actually skip diagnostics during lint execution. The current dylint_testing UI harness determines the crate name internally and cannot be controlled, preventing end-to-end validation of exclusion behaviour.

Proposed Solution

Create workspace fixture infrastructure to enable integration testing:

1. Fixture workspace structure: Create test fixtures under tests/fixtures/ with controlled workspace layouts, including:

   • A fixture crate that uses std::fs operations
   • A dylint.toml configuration with exclusions
   • Cargo.toml configurations for multiple test scenarios

2. Integration test harness: Implement tests using std::process::Command to:

   • Build and run the lint against fixture projects
   • Parse compiler output to count diagnostics
   • Assert that excluded crates produce zero diagnostics
   • Assert that non-excluded crates produce expected diagnostics

3. Test coverage: Validate both behaviours:

   • Crate in excluded_crates → no diagnostics
   • Crate not in excluded_crates → diagnostics emitted

References

• PR: Whitaker lint violations #109
• Comment: Whitaker lint violations #109 (comment)
• Requested by: @leynos

Notes

This infrastructure will benefit future lint development by enabling end-to-end testing of configuration-driven behaviour across the Whitaker lint suite.

[traycerai]

Warning

Rate limit exceeded. Please try after 171481 seconds.

[leynos]

@CodeRabbit plan

[coderabbitai]

Coding Plan

Summary

• The ticket's requested infrastructure (fixture workspaces, integration test harness, test coverage) already exists in crates/no_std_fs_operations/tests/
• The sole remaining gap is the missing workspace = false declaration in both fixture Cargo.toml files
• This fix ensures defensive workspace isolation, preventing the fixtures from being inadvertently resolved as workspace members if Cargo's behaviour or the workspace glob changes
• Verification confirms the existing tests function correctly after the fix

Design Choices

Design Choice 1: Should the integration tests be enabled in CI?

Options Considered:

1. Add CI workflow step to install cargo-dylint and run --ignored tests
2. Keep tests as manual opt-in, run only when explicitly requested with --ignored

Chosen Option: 2

Rationale: The external tooling dependencies make CI integration brittle; manual execution via cargo test -- --ignored is the established pattern for such tests in this codebase.

💡 User Tips

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

Implementation Steps

Fix Workspace Isolation in Fixture Projects

Add explicit workspace isolation declarations to both fixture Cargo.toml files, preventing any future possibility of accidental workspace member lookup when Cargo resolves these projects.

Task 1: Add `workspace = false` to Both Fixture Projects

Add the workspace = false key to each fixture's Cargo.toml to make workspace isolation explicit and defensive.

• Update crates/no_std_fs_operations/tests/fixtures/excluded_project/Cargo.toml to add workspace = false in the [package] section, placed after the edition field
• Update crates/no_std_fs_operations/tests/fixtures/non_excluded_project/Cargo.toml identically, maintaining consistency between fixtures
• Both files follow the same structure; apply the identical change to each

Task 2: Verify Integration Tests Execute Successfully

Confirm the existing integration tests pass with the workspace isolation fix applied.

• Run cargo test -p no_std_fs_operations -- --ignored to execute the #[ignore]-marked integration tests
• Verify excluded_crate_suppresses_diagnostics passes (excluded crate produces zero diagnostics)
• Verify non_excluded_crate_emits_diagnostics passes (non-excluded crate triggers the lint)
• Ensure cargo-dylint and dylint-link are installed before running; install via cargo install cargo-dylint dylint-link if absent

🤖 Prompt for AI agents

Add `workspace = false` to the `[package]` section of both fixture `Cargo.toml`
files to enforce explicit workspace isolation, then verify the integration tests
pass.

**Task 1.1 — Apply the fix to both fixtures:**
- Open `crates/no_std_fs_operations/tests/fixtures/excluded_project/Cargo.toml`
and insert `workspace = false` after the `edition` field in the `[package]`
section
- Open
`crates/no_std_fs_operations/tests/fixtures/non_excluded_project/Cargo.toml` and
apply the identical change — insert `workspace = false` after the `edition`
field in the `[package]` section
- Ensure the structure of both files remains consistent with one another
- Make no other modifications to either file

**Task 1.2 — Verify the integration tests:**
- Confirm `cargo-dylint` and `dylint-link` are installed; if absent, install
them via `cargo install cargo-dylint dylint-link`
- Run `cargo test -p no_std_fs_operations -- --ignored` to execute the
`#[ignore]`-marked integration tests
- Confirm `excluded_crate_suppresses_diagnostics` passes (excluded crate
produces zero diagnostics)
- Confirm `non_excluded_crate_emits_diagnostics` passes (non-excluded crate
triggers the lint)

Research

The no_std_fs_operations lint crate already contains a complete integration testing infrastructure for validating excluded_crates configuration behaviour. The file tests/integration_exclusion.rs (199 lines) implements two #[ignore]-marked tests that invoke cargo dylint as a subprocess against fixture workspaces, checking that excluded crates suppress diagnostics whilst non-excluded crates emit them. Fixture workspaces exist at tests/fixtures/excluded_project/ and tests/fixtures/non_excluded_project/, each with Cargo.toml, dylint.toml, and src/lib.rs. The root workspace uses the glob crates/* which does not recurse into tests/fixtures/, so the fixtures are not currently pulled into the workspace. However, both fixture Cargo.toml files lack the explicit workspace = false declaration, creating a latent isolation risk.

---

🚀 Next Steps

🤖 All AI agent prompts combined

Add `workspace = false` to the `[package]` section of both fixture `Cargo.toml`
files to enforce explicit workspace isolation, then verify the integration tests
pass.

**Task 1.1 — Apply the fix to both fixtures:**
- Open `crates/no_std_fs_operations/tests/fixtures/excluded_project/Cargo.toml`
and insert `workspace = false` after the `edition` field in the `[package]`
section
- Open
`crates/no_std_fs_operations/tests/fixtures/non_excluded_project/Cargo.toml` and
apply the identical change — insert `workspace = false` after the `edition`
field in the `[package]` section
- Ensure the structure of both files remains consistent with one another
- Make no other modifications to either file

**Task 1.2 — Verify the integration tests:**
- Confirm `cargo-dylint` and `dylint-link` are installed; if absent, install
them via `cargo install cargo-dylint dylint-link`
- Run `cargo test -p no_std_fs_operations -- --ignored` to execute the
`#[ignore]`-marked integration tests
- Confirm `excluded_crate_suppresses_diagnostics` passes (excluded crate
produces zero diagnostics)
- Confirm `non_excluded_crate_emits_diagnostics` passes (non-excluded crate
triggers the lint)

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

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

---

💬 Have feedback or questions? Drop into our discord!

[leynos]

@coderabbitai I would prefer that we build these fixture crates outside of the repository rather than keeping them checked in verbatim

[coderabbitai]

I've updated the plan above based on your feedback. Ready to proceed when you are!

[leynos]

@CodeRabbit can this issue now be closed?

[coderabbitai]

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Check the current state of the fixture directories and integration test file
echo "=== Fixture directories ==="
fd . crates/no_std_fs_operations/tests/ --type f

echo ""
echo "=== excluded_project Cargo.toml ==="
cat crates/no_std_fs_operations/tests/fixtures/excluded_project/Cargo.toml 2>/dev/null || echo "FILE NOT FOUND"

echo ""
echo "=== non_excluded_project Cargo.toml ==="
cat crates/no_std_fs_operations/tests/fixtures/non_excluded_project/Cargo.toml 2>/dev/null || echo "FILE NOT FOUND"

echo ""
echo "=== Integration test file ==="
cat crates/no_std_fs_operations/tests/integration_exclusion.rs 2>/dev/null || echo "FILE NOT FOUND"

echo ""
echo "=== GitHub issue `#111` state ==="
gh issue view 111 --repo leynos/whitaker --json state,title,body,comments | jq '{state, title}'

Length of output: 8830

---

@leynos, not yet — the issue is still OPEN and your updated requirement hasn't been implemented.

Your last feedback on the plan was that you'd prefer the fixture crates to be built outside the repository (i.e., generated dynamically at test time) rather than kept as checked-in static files. The current state of the repo still has both fixtures checked in verbatim:

• crates/no_std_fs_operations/tests/fixtures/excluded_project/Cargo.toml
• crates/no_std_fs_operations/tests/fixtures/non_excluded_project/Cargo.toml

The isolation concern has been partially addressed — both fixtures now declare [workspace] as a standalone section, making each its own workspace root — but the static fixture files remain in the repository tree, and fixture_path() in the integration test still resolves to those checked-in paths.

To close this issue, the integration test harness would need to be updated to:

1. Generate the fixture crates (their Cargo.toml, dylint.toml, and src/lib.rs) into a temporary directory at test time (e.g. using tempfile::TempDir).
2. Point run_cargo_dylint at those generated directories instead of the checked-in tests/fixtures/ paths.
3. Remove the checked-in fixture directories from the repository.

Shall I produce a plan and updated implementation for this approach?

[leynos]

@CodeRabbit plan

[coderabbitai]

Coding Plan

Summary

• Delete the two static fixture directories (excluded_project/, non_excluded_project/) and their parent fixtures/ directory
• Implement a fixture generation helper that writes Cargo.toml, dylint.toml, and src/lib.rs into a tempfile::TempDir at test runtime
• Update both integration test functions to use the helper, eliminating the fixture_path() function
• Workspace isolation is resolved implicitly: fixtures in system temp directories cannot be mistakenly resolved as workspace members, so no workspace = false is required

Design Choices

Design Choice 1: Should the integration tests be enabled in CI?

Options Considered:

1. Add CI workflow step to install cargo-dylint and run --ignored tests
2. Keep tests as manual opt-in, run only when explicitly requested with --ignored

Chosen Option: 2

Rationale: The external tooling dependencies make CI integration brittle; manual execution via cargo test -- --ignored is the established pattern for such tests in this codebase.

💡 User Tips

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

Implementation Steps

Replace Static Fixtures with Dynamic Generation

Remove the checked-in fixture directories and implement runtime fixture generation using tempfile::TempDir. This eliminates workspace isolation concerns entirely—fixtures generated in system temp directories cannot be resolved as workspace members.

Task 1: Delete Static Fixture Directories

Remove the two static fixture directories that will be replaced by dynamic generation.

• Delete crates/no_std_fs_operations/tests/fixtures/excluded_project/ (contains Cargo.toml, dylint.toml, src/lib.rs)
• Delete crates/no_std_fs_operations/tests/fixtures/non_excluded_project/ (contains Cargo.toml, dylint.toml, src/lib.rs)
• Delete the now-empty crates/no_std_fs_operations/tests/fixtures/ directory

Task 2: Add tempfile Dev-Dependency

Add tempfile to the crate's dev-dependencies following the established workspace pattern.

• Update crates/no_std_fs_operations/Cargo.toml to add tempfile = { workspace = true } in [dev-dependencies]
• The workspace already declares tempfile = "3.19.1" in root Cargo.toml; this follows the pattern used by whitaker_sarif, bumpy_road_function, and installer

Task 3: Implement Fixture Generation Helper

Create a helper function in integration_exclusion.rs that generates fixture crates programmatically into a TempDir.

• Add a FixtureProject struct (or equivalent) holding tempfile::TempDir and providing access to the fixture root path
• Implement a builder or factory function accepting parameters: crate name (&str), whether the crate is excluded (bool)
• Generate Cargo.toml with the crate name, version "0.1.0", edition "2024", and empty [dependencies]—no workspace = false needed since the temp directory is outside the workspace root
• Generate dylint.toml with [no_std_fs_operations] section; set excluded_crates = ["<crate_name>"] when excluded, or excluded_crates = [] when not
• Generate src/lib.rs containing the std::fs::File::open usage that triggers the lint
• Return the struct, ensuring TempDir lifetime extends through test execution (drop cleans up automatically)

Task 4: Update Test Functions to Use Dynamic Fixtures

Modify the test functions to use the new fixture generation helper instead of static paths.

• Remove the fixture_path(name: &str) -> PathBuf helper function (no longer needed)
• Update excluded_crate_suppresses_diagnostics to generate a fixture with crate_name = "excluded_test_crate" and excluded = true, then pass the temp dir path to run_cargo_dylint
• Update non_excluded_crate_emits_diagnostics to generate a fixture with crate_name = "non_excluded_crate" and excluded = false, then pass the temp dir path to run_cargo_dylint
• Ensure run_cargo_dylint accepts &Path (or impl AsRef<Path>) for the fixture directory argument; the existing signature already takes &Path, so no change needed there

Task 5: Verify Integration Tests Execute Successfully

Confirm the refactored integration tests pass with dynamic fixture generation.

• Ensure cargo-dylint and dylint-link are installed; install via cargo install cargo-dylint dylint-link if absent
• Run cargo test -p no_std_fs_operations -- --ignored to execute the #[ignore]-marked integration tests
• Verify excluded_crate_suppresses_diagnostics passes (excluded crate produces zero diagnostics)
• Verify non_excluded_crate_emits_diagnostics passes (non-excluded crate triggers the lint)

🤖 Prompt for AI agents

Replace static fixture directories with runtime-generated temporary fixtures
using `tempfile::TempDir` across `crates/no_std_fs_operations/`. The goal is to
eliminate workspace isolation concerns by writing fixture files into system temp
directories at test time, rather than checking them in.

**Task 1.1 — Delete static fixture directories:**
- Remove `crates/no_std_fs_operations/tests/fixtures/excluded_project/`
(including `Cargo.toml`, `dylint.toml`, `src/lib.rs`)
- Remove `crates/no_std_fs_operations/tests/fixtures/non_excluded_project/`
(including `Cargo.toml`, `dylint.toml`, `src/lib.rs`)
- Remove the now-empty `crates/no_std_fs_operations/tests/fixtures/` directory

**Task 1.2 — Add `tempfile` dev-dependency:**
- In `crates/no_std_fs_operations/Cargo.toml`, add `tempfile = { workspace =
true }` under `[dev-dependencies]`
- Follow the existing pattern used by `whitaker_sarif`, `bumpy_road_function`,
and `installer`; the workspace root `Cargo.toml` already declares `tempfile =
"3.19.1"`

**Task 1.3 — Implement a fixture generation helper in
`tests/integration_exclusion.rs`:**
- Define a `FixtureProject` struct that owns a `tempfile::TempDir` and exposes
the fixture root path
- Implement a factory function accepting `crate_name: &str` and `excluded: bool`
- Write `Cargo.toml` into the temp dir with: crate name, version `"0.1.0"`,
edition `"2024"`, and empty `[dependencies]`—omit `workspace = false`
(unnecessary outside the workspace root)
- Write `dylint.toml` with a `[no_std_fs_operations]` section; set
`excluded_crates = ["<crate_name>"]` when `excluded` is `true`, or
`excluded_crates = []` when `false`
- Create `src/` subdirectory and write `src/lib.rs` containing the
`std::fs::File::open` call that triggers the lint
- Return the `FixtureProject` struct, ensuring the `TempDir` is kept alive for
the duration of the test (it cleans up on drop)

**Task 1.4 — Update test functions:**
- Remove the `fixture_path(name: &str) -> PathBuf` helper function entirely
- In `excluded_crate_suppresses_diagnostics`: call the factory with `crate_name
= "excluded_test_crate"` and `excluded = true`; pass the temp dir path to
`run_cargo_dylint`
- In `non_excluded_crate_emits_diagnostics`: call the factory with `crate_name =
"non_excluded_crate"` and `excluded = false`; pass the temp dir path to
`run_cargo_dylint`
- The existing `run_cargo_dylint` signature already accepts `&Path`, so make no
changes to that function's signature

**Task 1.5 — Verify:**
- Confirm `cargo-dylint` and `dylint-link` are installed; install via `cargo
install cargo-dylint dylint-link` if absent
- Run `cargo test -p no_std_fs_operations -- --ignored`
- Confirm `excluded_crate_suppresses_diagnostics` passes (zero diagnostics) and
`non_excluded_crate_emits_diagnostics` passes (lint triggered)

Research

The no_std_fs_operations lint crate already contains a complete integration testing infrastructure for validating excluded_crates configuration behaviour. The file tests/integration_exclusion.rs (199 lines) implements two #[ignore]-marked tests that invoke cargo dylint as a subprocess against fixture workspaces, checking that excluded crates suppress diagnostics whilst non-excluded crates emit them. Fixture workspaces currently exist as static directories at tests/fixtures/excluded_project/ and tests/fixtures/non_excluded_project/, each with Cargo.toml, dylint.toml, and src/lib.rs. Both fixture Cargo.toml files lack workspace = false, creating a latent isolation risk—however, this concern is resolved by moving to dynamic generation in a temp directory outside the workspace root.

---

🚀 Next Steps

🤖 All AI agent prompts combined

Replace static fixture directories with runtime-generated temporary fixtures
using `tempfile::TempDir` across `crates/no_std_fs_operations/`. The goal is to
eliminate workspace isolation concerns by writing fixture files into system temp
directories at test time, rather than checking them in.

**Task 1.1 — Delete static fixture directories:**
- Remove `crates/no_std_fs_operations/tests/fixtures/excluded_project/`
(including `Cargo.toml`, `dylint.toml`, `src/lib.rs`)
- Remove `crates/no_std_fs_operations/tests/fixtures/non_excluded_project/`
(including `Cargo.toml`, `dylint.toml`, `src/lib.rs`)
- Remove the now-empty `crates/no_std_fs_operations/tests/fixtures/` directory

**Task 1.2 — Add `tempfile` dev-dependency:**
- In `crates/no_std_fs_operations/Cargo.toml`, add `tempfile = { workspace =
true }` under `[dev-dependencies]`
- Follow the existing pattern used by `whitaker_sarif`, `bumpy_road_function`,
and `installer`; the workspace root `Cargo.toml` already declares `tempfile =
"3.19.1"`

**Task 1.3 — Implement a fixture generation helper in
`tests/integration_exclusion.rs`:**
- Define a `FixtureProject` struct that owns a `tempfile::TempDir` and exposes
the fixture root path
- Implement a factory function accepting `crate_name: &str` and `excluded: bool`
- Write `Cargo.toml` into the temp dir with: crate name, version `"0.1.0"`,
edition `"2024"`, and empty `[dependencies]`—omit `workspace = false`
(unnecessary outside the workspace root)
- Write `dylint.toml` with a `[no_std_fs_operations]` section; set
`excluded_crates = ["<crate_name>"]` when `excluded` is `true`, or
`excluded_crates = []` when `false`
- Create `src/` subdirectory and write `src/lib.rs` containing the
`std::fs::File::open` call that triggers the lint
- Return the `FixtureProject` struct, ensuring the `TempDir` is kept alive for
the duration of the test (it cleans up on drop)

**Task 1.4 — Update test functions:**
- Remove the `fixture_path(name: &str) -> PathBuf` helper function entirely
- In `excluded_crate_suppresses_diagnostics`: call the factory with `crate_name
= "excluded_test_crate"` and `excluded = true`; pass the temp dir path to
`run_cargo_dylint`
- In `non_excluded_crate_emits_diagnostics`: call the factory with `crate_name =
"non_excluded_crate"` and `excluded = false`; pass the temp dir path to
`run_cargo_dylint`
- The existing `run_cargo_dylint` signature already accepts `&Path`, so make no
changes to that function's signature

**Task 1.5 — Verify:**
- Confirm `cargo-dylint` and `dylint-link` are installed; install via `cargo
install cargo-dylint dylint-link` if absent
- Run `cargo test -p no_std_fs_operations -- --ignored`
- Confirm `excluded_crate_suppresses_diagnostics` passes (zero diagnostics) and
`non_excluded_crate_emits_diagnostics` passes (lint triggered)

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

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

---

💬 Have feedback or questions? Drop into our discord!