a808c395f9
CI / benchmark-publish (pull_request) Has been skipped
CI / lint (pull_request) Successful in 15s
CI / build (pull_request) Successful in 15s
CI / quality (pull_request) Successful in 17s
CI / typecheck (pull_request) Successful in 35s
CI / security (pull_request) Successful in 50s
CI / unit_tests (pull_request) Successful in 2m46s
CI / integration_tests (pull_request) Successful in 3m16s
CI / docker (pull_request) Successful in 40s
CI / coverage (pull_request) Successful in 5m6s
CI / lint (push) Successful in 13s
CI / quality (push) Successful in 16s
CI / build (push) Successful in 18s
CI / security (push) Successful in 32s
CI / typecheck (push) Successful in 35s
CI / benchmark-regression (push) Has been skipped
CI / unit_tests (push) Successful in 2m52s
CI / integration_tests (push) Successful in 3m8s
CI / docker (push) Successful in 39s
CI / coverage (push) Successful in 5m53s
CI / benchmark-publish (push) Successful in 16m55s
CI / benchmark-regression (pull_request) Successful in 33m0s
Add 53 new .feature files and corresponding step definition files targeting uncovered lines identified in build/coverage.xml. Fix AmbiguousStep conflicts in 7 pre-existing step files by disambiguating step text. New tests cover: ACP clients/facade, actor CLI/config, application container, ACMS service/strategies, async worker, automation profile CLI, autonomy guardrail, bridge, change model, config CLI/service, context service, cross-plan correction, database models, decision service, decomposition clustering/service, discovery handler, langchain chat provider, langgraph nodes, materializers, multi-project service, plan apply/CLI/lifecycle/model/ preflight/resume/service, PostgreSQL analyzer, project CLI/context CLI, provider registry, reactive application/route, repositories, resolver handler, resource registry service, resume model, retry patterns, sandbox protocol, server CLI, skill CLI/service, skills registry, subplan execution/service, system CLI, UKO loader, UoW, and YAML template engine. Closes #645
77 lines
3.8 KiB
Gherkin
77 lines
3.8 KiB
Gherkin
@phase1 @domain @unit_of_work @uow_coverage_boost
|
|
Feature: UnitOfWork coverage boost for uncovered code paths
|
|
As a developer maintaining the UnitOfWork infrastructure
|
|
I want thorough coverage of engine creation, checkpoint repository, and refresh
|
|
So that all code paths in unit_of_work.py are exercised
|
|
|
|
# ---------------------------------------------------------------------------
|
|
# Engine creation: non-SQLite URL (lines 90-93)
|
|
# ---------------------------------------------------------------------------
|
|
|
|
@uow_non_sqlite_engine
|
|
Scenario: UnitOfWork creates engine for non-SQLite database URL
|
|
Given a UnitOfWork configured with a non-SQLite database URL
|
|
When I access the engine property with mocked create_engine
|
|
Then the engine should be created via the non-SQLite code path
|
|
And the engine should not use SQLite-specific connect_args
|
|
|
|
# ---------------------------------------------------------------------------
|
|
# Engine creation: fresh in-memory SQLite not yet cached (lines 71-76)
|
|
# ---------------------------------------------------------------------------
|
|
|
|
@uow_fresh_memory_engine
|
|
Scenario: UnitOfWork creates new in-memory engine when cache is empty
|
|
Given the in-memory engine cache is cleared
|
|
And a UnitOfWork configured with an in-memory SQLite URL
|
|
When I access the in-memory engine property with mocked migrations
|
|
Then a new in-memory engine should be created and cached
|
|
And the cached engine should use SERIALIZABLE isolation
|
|
|
|
# ---------------------------------------------------------------------------
|
|
# Checkpoint repository access (lines 244-248)
|
|
# ---------------------------------------------------------------------------
|
|
|
|
@uow_checkpoints_repo
|
|
Scenario: UnitOfWorkContext exposes checkpoints repository
|
|
Given a UnitOfWorkContext backed by a mock session
|
|
When I access the checkpoints repository from the context
|
|
Then the checkpoints repository should be a CheckpointRepository instance
|
|
|
|
@uow_checkpoints_repo_cached
|
|
Scenario: UnitOfWorkContext caches checkpoints repository on repeated access
|
|
Given a UnitOfWorkContext backed by a mock session
|
|
When I access the checkpoints repository from the context twice
|
|
Then both accesses should return the same CheckpointRepository instance
|
|
|
|
# ---------------------------------------------------------------------------
|
|
# refresh() method (line 312)
|
|
# ---------------------------------------------------------------------------
|
|
|
|
@uow_refresh_entity
|
|
Scenario: UnitOfWorkContext.refresh delegates to session refresh
|
|
Given a UnitOfWorkContext backed by a mock session
|
|
When I call refresh with a dummy entity
|
|
Then session.refresh should have been called with that entity
|
|
|
|
# ---------------------------------------------------------------------------
|
|
# Non-SQLite engine options verification (lines 90-93)
|
|
# ---------------------------------------------------------------------------
|
|
|
|
@uow_non_sqlite_engine_options
|
|
Scenario: Non-SQLite engine uses default options without isolation_level override
|
|
Given a UnitOfWork configured with a postgresql-style database URL
|
|
When I trigger engine creation with mocked dependencies
|
|
Then create_engine should have been called without isolation_level
|
|
And create_engine should have been called with future=True
|
|
|
|
# ---------------------------------------------------------------------------
|
|
# In-memory engine cache hit vs miss (lines 70-78)
|
|
# ---------------------------------------------------------------------------
|
|
|
|
@uow_memory_engine_cache_hit
|
|
Scenario: UnitOfWork reuses cached in-memory engine on second instantiation
|
|
Given the in-memory engine cache is cleared
|
|
And a first UnitOfWork has already created an in-memory engine
|
|
When a second UnitOfWork accesses its engine property
|
|
Then the second engine should be the same object as the first
|