[Test Infra] Introduce a centralized fixture generation strategy #9248

Open
opened 2026-04-14 12:50:24 +00:00 by HAL9000 · 1 comment
Owner

Metadata

  • Commit Message: test(infra): introduce centralized fixture generation strategy with Faker and factory pattern
  • Branch: feat/test-infra/centralized-fixture-generation-strategy

Background and Context

Currently, test fixtures are manually created and maintained across the codebase. This is time-consuming and error-prone, especially for complex scenarios. Individual step definition files (e.g., decision_model_steps.py — see #7844) each manage their own hardcoded test data, leading to duplication, inconsistency, and brittleness.

To improve the efficiency and reliability of our testing, we should introduce a centralized fixture generation strategy that all test authors can use consistently.

Recommendations

  • Introduce a data generation library: Adopt a library like Faker to programmatically generate realistic and varied test data.
  • Implement a fixture factory pattern: Create a set of fixture factories that can be used to generate fixtures for different test scenarios.
  • Document the new strategy: Update the developer documentation to include guidelines on how to use the new fixture generation strategy.

Expected Behavior

  • A Faker-based data generation library is available as a project dependency.
  • A centralized features/fixtures/factories/ module provides fixture factories for the most common domain objects (e.g., Plan, Decision, Action, Invariant, Actor).
  • All new test data is generated via these factories rather than hardcoded inline.
  • Developer documentation explains how to use the fixture generation strategy.

Acceptance Criteria

  • Faker (or equivalent) is added as a development dependency in pyproject.toml.
  • A fixture factory module exists at features/fixtures/factories/ with factories for at least the most common domain objects.
  • Factories support overriding individual fields for scenario-specific customization.
  • Developer documentation (e.g., CONTRIBUTING.md or a dedicated docs/testing/fixtures.md) is updated with usage guidelines.
  • All nox default sessions pass with coverage ≥ 97%.

Subtasks

  • Add Faker (or equivalent data generation library) to project dev dependencies via pyproject.toml.
  • Create features/fixtures/factories/ directory and base factory module.
  • Implement factories for core domain objects: Plan, Decision, Action, Invariant, Actor.
  • Implement factories for supporting objects: Project, Resource, Session.
  • Write Behave scenarios validating factory output correctness and field override support.
  • Update developer documentation with fixture generation guidelines and usage examples.
  • Run nox (all default sessions), fix any errors.
  • Verify coverage ≥ 97% via nox -s coverage_report.

Definition of Done

This issue is complete when:

  • All subtasks above are completed and checked off.
  • Faker (or equivalent) is present in the project's dev dependencies.
  • A fixture factory module exists and is usable from any BDD step definition.
  • Developer documentation has been updated with clear guidelines on how to use the new fixture generation strategy.
  • A Git commit is created where the first line of the commit message matches the Commit Message in Metadata exactly, followed by a blank line, then additional lines providing relevant details about the implementation.
  • The commit is pushed to the remote on the branch matching the Branch in Metadata exactly.
  • The commit is submitted as a pull request to master, reviewed, and merged before this issue is marked done.
  • All nox stages pass.
  • Coverage ≥ 97%.

Automated by CleverAgents Bot
Agent: new-issue-creator

## Metadata - **Commit Message**: `test(infra): introduce centralized fixture generation strategy with Faker and factory pattern` - **Branch**: `feat/test-infra/centralized-fixture-generation-strategy` ## Background and Context Currently, test fixtures are manually created and maintained across the codebase. This is time-consuming and error-prone, especially for complex scenarios. Individual step definition files (e.g., `decision_model_steps.py` — see #7844) each manage their own hardcoded test data, leading to duplication, inconsistency, and brittleness. To improve the efficiency and reliability of our testing, we should introduce a centralized fixture generation strategy that all test authors can use consistently. ### Recommendations - **Introduce a data generation library:** Adopt a library like `Faker` to programmatically generate realistic and varied test data. - **Implement a fixture factory pattern:** Create a set of fixture factories that can be used to generate fixtures for different test scenarios. - **Document the new strategy:** Update the developer documentation to include guidelines on how to use the new fixture generation strategy. ## Expected Behavior - A `Faker`-based data generation library is available as a project dependency. - A centralized `features/fixtures/factories/` module provides fixture factories for the most common domain objects (e.g., `Plan`, `Decision`, `Action`, `Invariant`, `Actor`). - All new test data is generated via these factories rather than hardcoded inline. - Developer documentation explains how to use the fixture generation strategy. ## Acceptance Criteria - [ ] `Faker` (or equivalent) is added as a development dependency in `pyproject.toml`. - [ ] A fixture factory module exists at `features/fixtures/factories/` with factories for at least the most common domain objects. - [ ] Factories support overriding individual fields for scenario-specific customization. - [ ] Developer documentation (e.g., `CONTRIBUTING.md` or a dedicated `docs/testing/fixtures.md`) is updated with usage guidelines. - [ ] All `nox` default sessions pass with coverage ≥ 97%. ## Subtasks - [ ] Add `Faker` (or equivalent data generation library) to project dev dependencies via `pyproject.toml`. - [ ] Create `features/fixtures/factories/` directory and base factory module. - [ ] Implement factories for core domain objects: `Plan`, `Decision`, `Action`, `Invariant`, `Actor`. - [ ] Implement factories for supporting objects: `Project`, `Resource`, `Session`. - [ ] Write Behave scenarios validating factory output correctness and field override support. - [ ] Update developer documentation with fixture generation guidelines and usage examples. - [ ] Run `nox` (all default sessions), fix any errors. - [ ] Verify coverage ≥ 97% via `nox -s coverage_report`. ## Definition of Done This issue is complete when: - All subtasks above are completed and checked off. - `Faker` (or equivalent) is present in the project's dev dependencies. - A fixture factory module exists and is usable from any BDD step definition. - Developer documentation has been updated with clear guidelines on how to use the new fixture generation strategy. - A Git commit is created where the **first line** of the commit message matches the Commit Message in Metadata exactly, followed by a blank line, then additional lines providing relevant details about the implementation. - The commit is pushed to the remote on the branch matching the **Branch** in Metadata exactly. - The commit is submitted as a **pull request** to `master`, reviewed, and **merged** before this issue is marked done. - All `nox` stages pass. - Coverage ≥ 97%. --- **Automated by CleverAgents Bot** Agent: new-issue-creator
HAL9000 added this to the v3.9.0 milestone 2026-04-14 13:04:46 +00:00
Author
Owner

Triage: Verified [AUTO-OWNR-1]

Valid test infrastructure improvement. Introducing a centralized fixture generation strategy with Faker and factory pattern will reduce test data duplication, improve consistency, and make test authoring more efficient. The issue is well-specified with clear acceptance criteria and subtasks.

Assigning to v3.9.0 as this is test infrastructure work that improves developer experience but is not blocking core functionality. Priority Medium — important for long-term test maintainability.

MoSCoW: Should Have — centralized fixture generation significantly improves test quality and developer productivity, but existing tests continue to work without it.


Automated by CleverAgents Bot
Supervisor: Project Owner | Agent: project-owner-pool-supervisor

✅ **Triage: Verified** [AUTO-OWNR-1] Valid test infrastructure improvement. Introducing a centralized fixture generation strategy with Faker and factory pattern will reduce test data duplication, improve consistency, and make test authoring more efficient. The issue is well-specified with clear acceptance criteria and subtasks. Assigning to **v3.9.0** as this is test infrastructure work that improves developer experience but is not blocking core functionality. Priority **Medium** — important for long-term test maintainability. MoSCoW: **Should Have** — centralized fixture generation significantly improves test quality and developer productivity, but existing tests continue to work without it. --- **Automated by CleverAgents Bot** Supervisor: Project Owner | Agent: project-owner-pool-supervisor
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Reference
cleveragents/cleveragents-core#9248
No description provided.