TEST-INFRA: [test-data-quality] Replace ast.literal_eval with Gherkin Tables for Better Readability #5486

Open
opened 2026-04-09 06:59:37 +00:00 by HAL9000 · 1 comment
Owner

Metadata

  • Branch: test-infra/replace-ast-literal-eval-with-gherkin-tables
  • Commit Message: test(infra): replace ast.literal_eval with Gherkin tables for better readability
  • Milestone: (backlog — see note below)
  • Parent Epic: (to be linked — see orphan note below)

Background and context

During an analysis of the test infrastructure, it was observed that some Behave step implementations use ast.literal_eval to parse string representations of data structures, such as lists and dictionaries. An example of this pattern can be found in features/steps/actor_service_steps.py:

Then I should receive actors ['my-actor', 'another-actor']
@then("I should receive actors {actor_names}")
def step_should_receive_actors(context: Context, actor_names: str) -> None:
    expected = ast.literal_eval(actor_names)
    assert [actor.name for actor in context.listed_actors] == expected

While this approach works, it has several disadvantages:

  • Poor Readability: The string representation of the data structure can be hard to read, especially for complex data.
  • Error-Prone: It is easy to make syntax errors in the string representation of the data structure, which can lead to test failures that are hard to debug.
  • Not Idiomatic Gherkin: Gherkin has built-in support for passing tabular data to steps, which is the idiomatic way to handle this kind of scenario.

Expected behavior

To improve the readability and maintainability of the test suite, the use of ast.literal_eval in steps should be replaced with Gherkin tables. The example above could be rewritten as:

Then I should receive the following actors:
  | name          |
  | my-actor      |
  | another-actor |
@then("I should receive the following actors:")
def step_should_receive_following_actors(context: Context) -> None:
    expected = [row["name"] for row in context.table]
    assert [actor.name for actor in context.listed_actors] == expected

This approach is more readable, less error-prone, and more idiomatic Gherkin.

Subtasks

  • Identify all the step implementation files that use ast.literal_eval.
  • Update the feature files to use Gherkin tables instead of string representations of data structures.
  • Update the step implementation files to parse the Gherkin tables.
  • Ensure that all tests pass after the refactoring.

Definition of Done

This issue is complete when:

  • All subtasks above are completed and checked off.
  • 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%.

Duplicate Check

  • Search queries: "ast.literal_eval", "gherkin table"
  • Results: 0 for "gherkin table", 1 for "ast.literal_eval" (not a duplicate).
  • Reasoning: No existing issues cover the replacement of ast.literal_eval with Gherkin tables.

Backlog note: This issue was discovered during autonomous operation
on the test infrastructure analysis cycle. It does not block milestone completion and has been
placed in the backlog for human review and future milestone assignment.


Automated by CleverAgents Bot
Supervisor: Test Infrastructure | Agent: new-issue-creator

## Metadata - **Branch**: `test-infra/replace-ast-literal-eval-with-gherkin-tables` - **Commit Message**: `test(infra): replace ast.literal_eval with Gherkin tables for better readability` - **Milestone**: *(backlog — see note below)* - **Parent Epic**: *(to be linked — see orphan note below)* ## Background and context During an analysis of the test infrastructure, it was observed that some Behave step implementations use `ast.literal_eval` to parse string representations of data structures, such as lists and dictionaries. An example of this pattern can be found in `features/steps/actor_service_steps.py`: ```gherkin Then I should receive actors ['my-actor', 'another-actor'] ``` ```python @then("I should receive actors {actor_names}") def step_should_receive_actors(context: Context, actor_names: str) -> None: expected = ast.literal_eval(actor_names) assert [actor.name for actor in context.listed_actors] == expected ``` While this approach works, it has several disadvantages: * **Poor Readability:** The string representation of the data structure can be hard to read, especially for complex data. * **Error-Prone:** It is easy to make syntax errors in the string representation of the data structure, which can lead to test failures that are hard to debug. * **Not Idiomatic Gherkin:** Gherkin has built-in support for passing tabular data to steps, which is the idiomatic way to handle this kind of scenario. ## Expected behavior To improve the readability and maintainability of the test suite, the use of `ast.literal_eval` in steps should be replaced with Gherkin tables. The example above could be rewritten as: ```gherkin Then I should receive the following actors: | name | | my-actor | | another-actor | ``` ```python @then("I should receive the following actors:") def step_should_receive_following_actors(context: Context) -> None: expected = [row["name"] for row in context.table] assert [actor.name for actor in context.listed_actors] == expected ``` This approach is more readable, less error-prone, and more idiomatic Gherkin. ## Subtasks - [ ] Identify all the step implementation files that use `ast.literal_eval`. - [ ] Update the feature files to use Gherkin tables instead of string representations of data structures. - [ ] Update the step implementation files to parse the Gherkin tables. - [ ] Ensure that all tests pass after the refactoring. ## Definition of Done This issue is complete when: - All subtasks above are completed and checked off. - 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%. ### Duplicate Check - **Search queries:** "ast.literal_eval", "gherkin table" - **Results:** 0 for "gherkin table", 1 for "ast.literal_eval" (not a duplicate). - **Reasoning:** No existing issues cover the replacement of `ast.literal_eval` with Gherkin tables. > **Backlog note:** This issue was discovered during autonomous operation > on the test infrastructure analysis cycle. It does not block milestone completion and has been > placed in the backlog for human review and future milestone assignment. --- **Automated by CleverAgents Bot** Supervisor: Test Infrastructure | Agent: new-issue-creator
Author
Owner

⚠️ Orphan Issue — Needs Parent Epic Linking

This issue was created without a known parent Epic. Per CONTRIBUTING.md, regular issues must not be orphans — they must be linked to a parent Epic using Forgejo's dependency system (child blocks parent).

Action required: A human reviewer or the backlog-groomer agent should identify the appropriate parent Epic (likely within the Hardening/Testing workstream) and create the dependency link:

# Child issue BLOCKS parent Epic — correct direction
curl -s -X POST "https://git.cleverthis.com/api/v1/repos/cleveragents/cleveragents-core/issues/5486/blocks" \
  -H "Authorization: token <FORGEJO_PAT>" \
  -H "Content-Type: application/json" \
  -d '{"owner": "cleveragents", "repo": "cleveragents-core", "index": <PARENT_EPIC_NUMBER>}'

Suggested search: Look for an Epic related to "test infrastructure", "test quality", or "Behave/Gherkin improvements" in the Testing/Hardening workstream.


Automated by CleverAgents Bot
Supervisor: Test Infrastructure | Agent: new-issue-creator

⚠️ **Orphan Issue — Needs Parent Epic Linking** This issue was created without a known parent Epic. Per CONTRIBUTING.md, regular issues must not be orphans — they must be linked to a parent Epic using Forgejo's dependency system (child **blocks** parent). **Action required:** A human reviewer or the backlog-groomer agent should identify the appropriate parent Epic (likely within the Hardening/Testing workstream) and create the dependency link: ```bash # Child issue BLOCKS parent Epic — correct direction curl -s -X POST "https://git.cleverthis.com/api/v1/repos/cleveragents/cleveragents-core/issues/5486/blocks" \ -H "Authorization: token <FORGEJO_PAT>" \ -H "Content-Type: application/json" \ -d '{"owner": "cleveragents", "repo": "cleveragents-core", "index": <PARENT_EPIC_NUMBER>}' ``` Suggested search: Look for an Epic related to "test infrastructure", "test quality", or "Behave/Gherkin improvements" in the Testing/Hardening workstream. --- **Automated by CleverAgents Bot** Supervisor: Test Infrastructure | Agent: new-issue-creator
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.

Dependencies

No dependencies set.

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