Skip to main content

Leave Database Testing Guide

Summary​

This guide defines non-production coverage for the verified persistence model. No formal Leave-specific .NET test project was found; current evidence includes documentation tests and a Leave smoke script.

Audience​

Backend developers, QA engineers, architects, DevOps engineers, and integration-test owners.

Prerequisites​

Use a disposable PostgreSQL-compatible test database, synthetic tenant/employee identifiers, the current migration set, and test doubles for external Attendance, Workflow, and messaging boundaries.

Steps​

Use isolated disposable databases or approved test environments with synthetic records. Never run these scenarios against production.

Unit tests​

  • Verify LeaveRequest state transitions, cancellation return behavior, date/unit invariants, and event creation.
  • Verify LeaveBalance availability, normalization, usage reversal, carry-forward, and encashment guards without inventing formulas.
  • Verify LeaveDayCalculator Holiday/weekly-off exclusions and policy-default behavior.

Repository integration tests​

  • Confirm tenant-filtered identity lookup, approved-overlap date logic, active policy resolution, balance exact lookup, and ordered queries.
  • Confirm Leave-type, policy, and balance unique constraints reject duplicates within a tenant but permit equivalent values across tenants.
  • Confirm Holiday date and weekly-off day indexes are non-unique and do not imply uniqueness.
  • Confirm timeline ordering/cap, outbox polling order/batch, tracked-query behavior, and delete/replace semantics.

Tenant-isolation tests​

  • Exercise each of the 11 global filters with two synthetic tenants, a missing tenant, and the safely supported privileged context.
  • Review every IgnoreQueryFilters path for an explicit tenant predicate.
  • Verify outbox operational polling is intentionally unfiltered and appropriately restricted at the service boundary.

Consumer and inbox tests​

  • Verify Employee-profile insert/update, same-event duplicate handling, older-event rejection, tenant/identity validation, inactive-state projection, audit creation, save-before-ack, and retry on failure.
  • Record that only last-event fields exist; test non-consecutive replay behavior as a known gap rather than assuming a full inbox ledger.

Transaction tests​

  • Force a failure inside one SaveChanges call and verify aggregate, audit/timeline, and newly added outbox rows roll back together.
  • Separately test failures between request/decision commits and balance commits, Workflow start and correlation save, and callback decision and balance update.
  • Verify approved cancellation reverses usage on the successful path and characterize recovery when the second save fails.

Migration tests​

  • Apply all three migrations to an empty disposable database and compare the result with the snapshot.
  • Upgrade from each prior migration, verify 12 objects/16 indexes/four unique indexes/no foreign keys, and validate projection/Workflow additions.
  • Validate development seeding only in a Development test host and confirm repeated execution does not duplicate seeded object groups.

Foundation and compatibility tests​

  • Persist/query carry-forward and encashment Foundation records without claiming orchestration availability.
  • Compare legacy/extracted request, balance, Holiday, and weekly-off identifiers/semantics using synthetic data.
  • Test cutover/rollback reconciliation assumptions separately; gateway routing alone is not a database parity test.

Validation or Expected Result​

All assertions must match the current model totals: one context, 12 objects, 16 explicit indexes, four unique indexes, no foreign keys, 11 filtered objects, three migrations, and no general inbox table. A failed test must leave the disposable environment recoverable and must not be worked around by editing production data.

Troubleshooting​

If results differ, first confirm the migration level and model snapshot, tenant context, filter-bypass usage, test database isolation, and external test-double behavior. Classify unexplained parity, replay, or cross-save recovery behavior as Requires confirmation and preserve the failed evidence for review.

Source References​

  • microservices/src/leave-service/Infrastructure/LeaveDbContext.cs
  • microservices/src/leave-service/Infrastructure/Persistence.cs
  • microservices/src/leave-service/Application/LeaveWorkflows.cs
  • microservices/src/leave-service/Messaging/EmployeeProfileConsumer.cs
  • microservices/src/leave-service/Infrastructure/DevelopmentSeeder.cs
  • microservices/scripts/smoke-leave.ps1

See Also​

Keywords​

  • Repository testing
  • Migration testing
  • Tenant isolation testing

Revision Information​

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