Skip to content

feat: isolate signer integration tests from the development database #220

@sergey3bv

Description

@sergey3bv

Summary

Signer integration tests (signer/tests/permission_validation_tests.rs and related integration-tests) connect via DATABASE_URL and insert fixture data (including tenant_id = 1) into whatever Postgres instance that URL points to, with no dedicated test database or documented rollback strategy.

Problem or Opportunity

Developers and CI risk polluting a shared local database, conflicting with real or manual data on the same tenant, and flaky or surprising results when tests run in parallel or alongside normal app usage.

Proposed Approach

Introduce a test-specific database or equivalent isolation (for example TEST_DATABASE_URL pointing at a separate DB with migrations applied, or ephemeral DB creation / containerized Postgres for CI), centralize connection setup for signer integration tests, and document the required env vars and workflow in development and CI.

Alternatives Considered

  • Reserved tenant IDs only (lighter change but weaker isolation);
  • Per-test transactions with restricted parallelism;
  • Full test containers-based Postgres for maximum portability at higher setup cost.

Mockups, Logs, or References

TODO comment

// TODO: Use test-specific database with isolation

Related helpers also appear in signer/tests/client_pubkey_tests.rs and signer/src/signer_daemon.rs.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions