Files
temp/features/automation_profile_cli_coverage_boost_r2.feature
freemo 051ee7c290 test(coverage): add Behave BDD tests to improve coverage across 52 source files
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
2026-03-20 21:22:10 +00:00

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