Skip to main content

Attendance Database Testing Guide

Summary​

Test Attendance persistence against isolated, disposable PostgreSQL infrastructure. No Attendance-specific formal .NET test project is present in the current backend source.

Audience​

  • Backend developers, QA engineers, DevOps engineers, and release reviewers

Prerequisites​

  • Use isolated, disposable PostgreSQL infrastructure and synthetic data.
  • Apply the current migrations and select a tenant context appropriate to each case.

Procedure​

Implement the following test layers and retain repeatable evidence for each expected behavior.

Test layers​

Unit tests​

Test domain-only date normalization, assignment range overlap, lifecycle transitions, and policy-rule collection behavior. These tests do not prove mappings or constraints.

Repository integration tests​

Verify employee/date lookup, tenant predicates, chronological punch reads, pending reopen lookup, weekly-off lookup, active/default Shift and policy selection, policy-rule persistence, employee-profile upsert, and snapshot replacement. Explicitly demonstrate that application-only invariants need orchestration.

Migration tests​

Apply all three migrations to an empty disposable database, compare the resulting model with the snapshot, then test supported forward upgrade from each prior migration. Treat rollback as a separate risk test; never target production.

Tenant-isolation tests​

Use two tenant contexts and a privileged test context. Cover every filtered object and separately verify the unfiltered operational outbox behavior. Include raw/backfill queries in review.

Backfill and parity tests​

Use synthetic source data. Verify dry-run writes nothing, apply is idempotent, resume skips completed tenants, compatibility identifiers survive, warnings are actionable, and validators detect count/content differences.

Transaction tests​

Force failure before and during save to verify business/outbox rollback. Test audit/timeline participation when written before the same save, and document commands that use two saves. Simulate external Payroll failure separately because it is not transactional with PostgreSQL.

Required test matrix​

ConcernExpected evidence
Daily uniquenessApplication prevents normal duplicates; test database permits them unless behavior changes
Reopen uniquenessConcurrent test exposes or controls application-only race
Assignment overlapDomain and repository tests; no database constraint claimed
DefaultsWeekly-off and default-policy unique constraints reject duplicates
SnapshotUnique period and update-in-place behavior
Audit/timelineExpected operation creates tenant-scoped entries
OutboxBusiness row and event row commit or roll back together
MigrationFresh and upgrade paths match the snapshot
ReconciliationSupported Time Office source and target reach parity

Test data must be synthetic and must not contain employee, customer, credential, or deployed-environment information.

Validation or Expected Result​

All tests must produce deterministic pass/fail evidence, leave no persistent shared-environment data, and distinguish database constraints from application-only checks.

Troubleshooting​

If results differ by provider, rerun against disposable PostgreSQL because an in-memory provider does not reproduce relational constraints. If tenant results leak across cases, verify context lifetime and tenant setup before diagnosing repository behavior.

Source References​

  • microservices/src/attendance-service/Infrastructure/AttendanceDbContext.cs
  • microservices/src/attendance-service/Infrastructure/Persistence.cs
  • microservices/src/attendance-service/Infrastructure/Migrations/AttendanceDbContextModelSnapshot.cs
  • microservices/src/attendance-service/Backfill/ShiftPolicyBackfillValidator.cs

See Also​

Keywords​

  • Attendance persistence
  • EF Core
  • PostgreSQL

Revision Information​

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