Skip to main content

Notification Database Testing

Summary​

Database behavior is exercised only through the end-to-end smoke script. No test project in the repository references NotificationDbContext, and no mapping, migration or repository test exists.

Audience​

Engineers, QA, DevOps engineers, architects and support.

Database testing​

Implemented coverage​

The smoke script is the only automated artifact touching persistence. It requires a reachable PostgreSQL instance, boots the service so migrations apply automatically, and then verifies persistence indirectly through API responses.

Persistence behaviors it does exercise, by consequence rather than by direct assertion:

  • Migration success — the service cannot start and serve if migration fails.
  • Default-template seeding — the template list filtered to active rows returns the seeded set.
  • Template versioning — creating a template for an existing key and channel produces a new version.
  • Template in-place update — the update endpoint's response reflects the modified row.
  • Message persistence and status transitions — the inbox, single-message and failed-queue reads reflect the expected states.
  • Delivery-attempt rows — the attempts read returns rows after a forced failure and retry.
  • Idempotency — the processed-event lookup returns a row, and re-dispatching the same event is suppressed.
  • Audit rows — the audit query filtered by event returns the stage trail.

Verified absence​

  • No .csproj in the repository references NotificationDbContext or the notification service outside the service project itself.
  • No mapping test asserting table names, lengths, required flags or index definitions.
  • No migration test — no up-and-down round trip, no idempotency check, no drift detection against the snapshot.
  • No repository test, because there is no repository.
  • No integration test using an in-memory provider, a SQLite substitute or a containerised database.
  • No concurrency test exercising the duplicate-event, recipient-upsert or template-version race windows.
  • No tenant-isolation test.
  • No seeding test asserting idempotency on a second run.

The following do not exist and are recorded as recommendations only.

  • Model-fidelity tests asserting the seven table names, the 14 index names and the four unique constraints, which would catch accidental mapping drift.
  • A migration round-trip test and a snapshot-drift check in continuous integration.
  • Containerised integration tests for the three identified race windows — these would currently demonstrate the unhandled unique-violation behavior described in concurrency.
  • A tenant-isolation test asserting that the administrative reads are cross-tenant, pinning current behavior so that a future change is deliberate.
  • A seeder idempotency test asserting that a second startup inserts nothing.

Classification​

Partial — indirect smoke coverage is Implemented; dedicated database testing is Not implemented.

Requires confirmation​

Whether the smoke script runs in continuous integration, and who owns database test coverage, require confirmation.

See Also​

Keywords​

  • Notification database
  • Database Testing
  • Draft database documentation

Source References​

  • microservices/scripts/smoke-notification.ps1
  • microservices/src/notification-service/Infrastructure/NotificationDbContext.cs
  • microservices/src/notification-service/Infrastructure/Migrations/20260705113059_InitialNotificationSchema.cs
  • microservices/src/notification-service/Seed/DefaultTemplateSeeder.cs

Revision Information​

  • Status: Draft
  • Last reviewed: 2026-07-21
  • Review cycle: Quarterly