Employee Event Integration Testing Guide
Summary
This guide defines public-safe checks for event triggers, domain-to-contract mapping, outbox atomicity, serialization, duplicate handling, and failure recovery. It does not provide production broker settings or real employee data.
Audience
- Backend developers, QA engineers, and integration-test authors
Prerequisites
- An isolated approved test environment
- Synthetic non-personal test records
- Access to the Employee Service test assembly and relevant consumer tests
- A disposable database and, only when delivery is in scope, an approved disposable broker
Steps
- Exercise each aggregate method and assert the exact domain-event type and no-op behavior.
- Save through
EmployeeDbContextand assert a matching version-one outbox contract for all seven mappings. - Verify Employee data and its outbox row commit or roll back together.
- Serialize and deserialize each contract using the shared serializer; assert metadata and nullable-field behavior without snapshotting personal values.
- Invoke the shared processor explicitly in the test composition, because Employee Service has no confirmed hosted relay.
- For Created, Updated, and Employment-status events, test only the consumers listed in the consumer landscape.
- Redeliver the same event identifier and verify each consumer's implemented duplicate behavior.
- Deliver an older projection event where a consumer implements an occurrence watermark and verify it is ignored.
- Simulate publisher and consumer failure, then verify failed/requeue state without exposing payloads in test output.
Validation or Expected Result
Expected results include one contract mapping for each domain event, no event for unchanged manager/department/status values, two ordered domain events for a real status change, and no claimed delivery for a relay that was not explicitly invoked by the test.
No dedicated backend test project covering the full Employee event path was found in the reviewed source. Existing automated coverage is therefore Requires confirmation, and the cases above are recommended future coverage rather than a report of passing backend tests.
Troubleshooting
- If no outbox row appears, confirm the mutation raised a domain event and the save used
EmployeeDbContext.SaveChangesAsync. - If a message remains pending or failed, confirm the test explicitly invokes
IOutboxProcessor; do not assume Employee Service hosts a relay. - If a consumer ignores a message, confirm the event type is in that consumer's source-defined subscription set.
- If a delivery repeats, validate the event identifier and consumer-specific idempotency store or watermark.
- If contract parsing fails, compare property names and types with the shared record; do not compensate by inventing undocumented aliases.
Source References
microservices/src/employee-service/Domain/Employees/Employee.csmicroservices/src/employee-service/Infrastructure/EmployeeDbContext.csmicroservices/src/employee-service/Infrastructure/Persistence.csmicroservices/src/shared-kernel/Outbox/IntegrationEventJsonSerializer.csmicroservices/src/shared-kernel/Messaging/OutboxProcessor.csmicroservices/src/leave-service/Messaging/EmployeeProfileConsumer.csmicroservices/src/payroll-service/Messaging/PayrollReadModelConsumer.csmicroservices/src/document-service/Messaging/DocumentReadModelConsumer.cs
Related Articles
See Also
Keywords
- Event integration tests
- Contract tests
- Failure simulation
Revision Information
- Status: Draft
- Last reviewed: 2026-07-15
- Review cycle: Quarterly