Skip to content

test: add integration tests for lazy registry promotion pattern#1117

Merged
stack72 merged 1 commit intomainfrom
add-lazy-registry-promotion-tests
Apr 6, 2026
Merged

test: add integration tests for lazy registry promotion pattern#1117
stack72 merged 1 commit intomainfrom
add-lazy-registry-promotion-tests

Conversation

@stack72
Copy link
Copy Markdown
Contributor

@stack72 stack72 commented Apr 6, 2026

Summary

Adds regression guard tests for the lazy registry promotion pattern introduced by PR #1089 and fixed by PR #1116. These tests would have caught the ensureTypeLoaded() regression before it reached UAT.

Category 1: Registry invariant tests (8 tests, fresh instances)

Documents the contract that get() returns undefined for lazy entries and ensureTypeLoaded() must be called to promote them. One positive + one negative test for each of the four registries (vault, datastore, driver, report). These pass regardless of the fix — they test the registry itself, not consumers.

Category 2: Consumer regression tests (2 tests, global singletons)

Verifies that resolveVaultType() and resolveDatastoreType() promote lazy entries so callers can safely use get() afterwards. The critical assertion:

// After resolution, get() must return the type — not undefined.
const result = vaultTypeRegistry.get(typeName);
assertNotEquals(result, undefined,
  "get() must return the type after resolveVaultType() — " +
  "if this fails, resolveVaultType() is not calling ensureTypeLoaded()");

Without PR #1116: resolveVaultType() calls has() (returns true for lazy) and returns true, but never calls ensureTypeLoaded() — so get() returns undefined and the test fails.

With PR #1116: resolveVaultType() calls ensureTypeLoaded() first, promoting the lazy entry — so get() returns the type and the test passes.

Test Plan

  • deno run test integration/lazy_registry_promotion_test.ts — 10 passed, 0 failed
  • deno check — clean
  • deno lint — clean
  • deno fmt --check — clean

🤖 Generated with Claude Code

Adds 10 tests verifying the lazy registry promotion contract introduced
by PR #1089 and fixed by PR #1116:

Category 1 (8 tests, fresh instances): Documents the registry invariant
that get() returns undefined for lazy entries and ensureTypeLoaded()
must be called first to promote them. Covers all four registries (vault,
datastore, driver, report).

Category 2 (2 tests, global singletons): Verifies that resolveVaultType()
and resolveDatastoreType() promote lazy entries before returning, so
callers can safely use get() afterwards. These tests would have caught
the PR #1089 regression — they fail without the ensureTypeLoaded() calls
added in PR #1116.

Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>
Copy link
Copy Markdown

@github-actions github-actions Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

Well-structured integration tests that document and guard the lazy registry promotion invariant. The two-category approach (registry-level invariants + consumer regression tests) is thoughtful — Category 1 tests the contract itself, Category 2 catches the actual bug that shipped.

Blocking Issues

None.

Suggestions

  1. Global singleton mutation in Category 2 tests: The tests call setTypeLoader() on the global vaultTypeRegistry and datastoreTypeRegistry singletons. This is mitigated by UUID-based type names, but if a future test depends on the previously-set loader, it would silently get the test's fake loader instead. Consider adding a cleanup step (e.g., restoring the original loader) via a try/finally or Deno test sanitizer. Low risk given the current test suite, so non-blocking.

LGTM — good regression guards for the lazy promotion pattern.

@stack72 stack72 merged commit 6d9bac1 into main Apr 6, 2026
10 checks passed
@stack72 stack72 deleted the add-lazy-registry-promotion-tests branch April 6, 2026 17:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant