forked from HAL9000/cleveragents-core
051ee7c290
Added 52 new .feature files and corresponding _steps.py files targeting previously uncovered code paths in the following areas: - TUI layer: app, commands, persona (state/schema/registry), widgets, input (shell_exec, reference_parser) - Application services: plan lifecycle/service/executor, session, project, repo indexing, correction, checkpoint, actor, llm_actors, strategy coordinator, resource file watcher, service retry wiring - CLI commands: session, resource, repl, plan, db, automation_profile - Domain models: retry_policy, resource_type, cost_budget, docker_compose_analyzer, detail_level, _sql_string_aware, _postgresql_helpers - Core: circuit_breaker, retry_service_patterns - Infrastructure: repositories, transaction_sandbox, strategy_registry, plugins/loader, container - Config: settings - Agents: plan_generation, context_analysis, auto_debug - A2A: facade All new tests follow the Behave/Gherkin BDD standard. Resolved step definition collisions with unique prefixes. Fixed Alembic fileConfig logger disabling issue (disable_existing_loggers=False). ISSUES CLOSED: #1068
34 lines
1.7 KiB
Gherkin
34 lines
1.7 KiB
Gherkin
Feature: Automation Profile CLI _get_service coverage boost
|
|
As a developer
|
|
I want to cover the _get_service function in automation_profile CLI module
|
|
So that the uncovered lines 51, 53, 54, 56, 57, 59, 63-66 are exercised
|
|
|
|
Background:
|
|
Given the automation profile CLI module is imported for r2 coverage
|
|
|
|
# -----------------------------------------------------------------
|
|
# Direct invocation of _get_service (lines 51-66)
|
|
# -----------------------------------------------------------------
|
|
|
|
Scenario: _get_service creates AutomationProfileService with database-backed repo
|
|
Given a mock container returning an in-memory SQLite database URL
|
|
When I call _get_service directly
|
|
Then the returned object should be an AutomationProfileService instance
|
|
And the service should have a repository attached
|
|
|
|
Scenario: _get_service uses the database URL from the container
|
|
Given a mock container returning a custom SQLite database URL "sqlite:///tmp/test_r2.db"
|
|
When I call _get_service directly
|
|
Then the returned object should be an AutomationProfileService instance
|
|
|
|
Scenario: _get_service creates a working service that can list profiles
|
|
Given a mock container returning an in-memory SQLite database URL with tables created
|
|
When I call _get_service directly
|
|
Then the returned service should be able to list profiles without error
|
|
|
|
Scenario: _get_service imports and wires all required components
|
|
Given a mock container returning an in-memory SQLite database URL
|
|
When I call _get_service and inspect the internals
|
|
Then the service repository should use a sessionmaker bound to an engine
|
|
And the repository should have auto_commit enabled
|