brent.edwards
5437c73420
CI / lint (push) Has been cancelled
CI / e2e_tests (push) Has been cancelled
CI / typecheck (push) Has been cancelled
CI / build (push) Has been cancelled
CI / integration_tests (push) Has been cancelled
CI / quality (push) Has been cancelled
CI / benchmark-publish (push) Has been cancelled
CI / security (push) Has been cancelled
CI / helm (push) Has been cancelled
CI / unit_tests (push) Has been cancelled
CI / docker (push) Has been cancelled
CI / status-check (push) Has been cancelled
CI / coverage (push) Has been cancelled
CI / benchmark-regression (push) Has been cancelled
Add a process-global `_INITIALIZED_DBS: set[str]` to `features/environment.py` that caches database URLs after `_fast_init_or_upgrade` has processed them. On subsequent calls with the same URL, the function returns immediately — skipping all URL parsing, path extraction, prefix matching, and `stat()` syscalls that previously executed on every new `UnitOfWork` instance. The cache is cleared at the start of each scenario in `before_scenario` to prevent cross-scenario state leaks, since each scenario receives fresh temp-DB paths via `tempfile.mktemp()`. Four new Behave scenarios validate cache hits on repeated calls, cache clearing between scenarios, and non-caching of non-matching-prefix URLs. Estimated savings: ~65,000 unnecessary function-body executions eliminated per full test run (~7 UnitOfWork instantiations × ~10,700 scenarios). ISSUES CLOSED: #735 Reviewed-by: Jeffrey Phillips Freeman <jeffrey.freeman@cleverthis.com> Co-authored-by: Brent E. Edwards <brent.edwards@cleverthis.com> Co-committed-by: Brent E. Edwards <brent.edwards@cleverthis.com>
98 lines
4.6 KiB
Gherkin
98 lines
4.6 KiB
Gherkin
Feature: Fast init_or_upgrade early-return behavior
|
|
As the test harness
|
|
I need _fast_init_or_upgrade to skip Alembic migrations for existing databases
|
|
So that parallel test execution does not hang on redundant migrations
|
|
|
|
Background:
|
|
Given the fast-init template-DB patch is installed
|
|
|
|
@mock_only
|
|
Scenario: Non-empty database with matching prefix skips original migration
|
|
Given a non-empty SQLite database file with a matching scenario prefix
|
|
When I call init_or_upgrade on the fast-init database
|
|
Then the original init_or_upgrade should not have been invoked
|
|
And the database file content should be unchanged
|
|
|
|
@mock_only
|
|
Scenario: Template is copied for a new database with matching prefix
|
|
Given a non-existent SQLite database path with a matching scenario prefix
|
|
When I call init_or_upgrade on the fast-init database
|
|
Then the database file should be a copy of the template
|
|
And the original init_or_upgrade should not have been invoked
|
|
|
|
@mock_only
|
|
Scenario: Existing empty database with matching prefix copies template
|
|
Given an empty SQLite database file with a matching scenario prefix
|
|
When I call init_or_upgrade on the fast-init database
|
|
Then the database file should be a copy of the template
|
|
And the original init_or_upgrade should not have been invoked
|
|
|
|
@mock_only
|
|
Scenario: Non-matching prefix delegates to original init_or_upgrade
|
|
Given a SQLite database URL whose filename has a non-matching prefix
|
|
When I call init_or_upgrade on the fast-init database
|
|
Then the original init_or_upgrade should have been invoked exactly once
|
|
|
|
@mock_only
|
|
Scenario: In-memory SQLite delegates to original init_or_upgrade
|
|
Given an in-memory SQLite database URL for fast-init testing
|
|
When I call init_or_upgrade on the fast-init database
|
|
Then the original init_or_upgrade should have been invoked exactly once
|
|
|
|
@mock_only
|
|
Scenario: Non-SQLite URL delegates to original init_or_upgrade
|
|
Given a non-SQLite database URL for fast-init testing
|
|
When I call init_or_upgrade on the fast-init database
|
|
Then the original init_or_upgrade should have been invoked exactly once
|
|
|
|
@mock_only
|
|
Scenario: Bare sqlite:// URL delegates to original init_or_upgrade
|
|
Given a bare sqlite:// database URL for fast-init testing
|
|
When I call init_or_upgrade on the fast-init database
|
|
Then the original init_or_upgrade should have been invoked exactly once
|
|
|
|
@mock_only
|
|
Scenario: Delegation forwards runner instance and keyword arguments
|
|
Given a non-SQLite database URL for fast-init testing
|
|
When I call init_or_upgrade with keyword arguments on the fast-init database
|
|
Then the original init_or_upgrade should have been invoked exactly once
|
|
And the original should have received the runner instance and keyword arguments
|
|
|
|
# -----------------------------------------------------------------------
|
|
# Process-global _INITIALIZED_DBS cache (issue #735)
|
|
# -----------------------------------------------------------------------
|
|
|
|
@mock_only
|
|
Scenario: Second call for the same non-empty DB skips all logic via global cache
|
|
Given a non-empty SQLite database file with a matching scenario prefix
|
|
And the initialized-DB cache is cleared
|
|
When I call init_or_upgrade on the fast-init database
|
|
And I call init_or_upgrade on the fast-init database a second time
|
|
Then the second init_or_upgrade call should have been a cache hit
|
|
And the database file content should be unchanged
|
|
|
|
@mock_only
|
|
Scenario: Second call for a newly-copied template DB skips all logic via global cache
|
|
Given a non-existent SQLite database path with a matching scenario prefix
|
|
And the initialized-DB cache is cleared
|
|
When I call init_or_upgrade on the fast-init database
|
|
And I call init_or_upgrade on the fast-init database a second time
|
|
Then the second init_or_upgrade call should have been a cache hit
|
|
And the database file should be a copy of the template
|
|
|
|
@mock_only
|
|
Scenario: Global cache is cleared between scenarios
|
|
Given a non-empty SQLite database file with a matching scenario prefix
|
|
And the initialized-DB cache is cleared
|
|
When I call init_or_upgrade on the fast-init database
|
|
Then the URL should be present in the initialized-DB cache
|
|
When the initialized-DB cache is cleared for a new scenario
|
|
Then the URL should not be present in the initialized-DB cache
|
|
|
|
@mock_only
|
|
Scenario: Non-matching prefix URLs are not added to the global cache
|
|
Given a SQLite database URL whose filename has a non-matching prefix
|
|
And the initialized-DB cache is cleared
|
|
When I call init_or_upgrade on the fast-init database
|
|
Then the URL should not be present in the initialized-DB cache
|