Files
cleveragents-core/features/api_naming_conventions.feature
T
HAL9000 1a485045cc fix(api-naming): resolve AmbiguousStep error and lint failures in BDD tests
- Rename duplicate step text 'both methods follow the same naming pattern'
  to 'both current item methods follow the same naming pattern' in the
  Consistent current item methods scenario to resolve AmbiguousStep error
- Fix lint violations: remove unused imports (pathlib.Path, ast), fix
  import ordering (I001), remove trailing whitespace on blank lines (W293)
- Rewrite step definitions to use AST-based method checking instead of
  importing service classes directly, avoiding heavy initialization hangs
2026-06-06 00:23:30 -04:00

49 lines
2.0 KiB
Gherkin

Feature: Unified API Naming Conventions
As a developer
I want consistent API naming conventions across all service classes
So that the API is predictable and easy to learn
Background:
Given a CleverAgents project is initialized
And the project service is available
And the plan service is available
Scenario: ProjectService uses create_project method
When I create a project using create_project method
Then the project is successfully created
And the project is stored in the database
Scenario: ProjectService.create_project is the primary method
When I call ProjectService.create_project
Then it should create a new project
And the method should have full type annotations
Scenario: PlanService uses get_plan_by_name method
Given a project with a plan named "test-plan"
When I retrieve the plan using get_plan_by_name method
Then the plan is successfully retrieved
And the plan name matches "test-plan"
Scenario: PlanService.get_plan_by_name replaces switch_to_plan
When I call PlanService.get_plan_by_name with a plan name
Then it should return the plan with that name
And the method should have full type annotations
Scenario: Consistent listing methods across services
When I list projects using list_projects
And I list plans using list_plans
Then both methods follow the same naming pattern
And both methods return lists of their respective entities
Scenario: Consistent current item methods across services
When I get the current project using get_current_project
And I get the current plan using get_current_plan
Then both current item methods follow the same naming pattern
And both methods return the current entity or None
Scenario: All service methods have full type annotations
When I inspect all public methods in service classes
Then all methods should have complete type annotations
And no type: ignore comments should be present
And all methods should pass pyright type checking