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
|