cleveragents/cleveragents-core
4
0
Fork 3
Code Issues 6.0k Pull Requests 115 Actions Packages Projects Releases Wiki Activity

test(api-naming): add BDD tests for unified API naming conventions

Browse Source 
- Add feature file for API naming conventions testing
- Add step definitions for API naming convention scenarios
- Tests verify consistent naming patterns across services
- Tests check for full type annotations on all public methods
This commit is contained in:
HAL 9000
2026-04-19 01:14:37 +00:00
committed by Forgejo
parent 98869e4d4a
commit 1cf8451168
2 changed files with 264 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
features/api_naming_conventions.feature
+48
View File
@@ -0,0 +1,48 @@
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 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