✅ Consider encapsulating DbContext in integration tests

Cc: @danielmackay

Hi @SSWConsulting/ssw-saw

Pain

Because the DbContext is scoped, the instance injected into the tests is different to the instance injected into the query handler. This can result in unexpected effects - as a scoped DbContext is a unit of work, saving changes in one instance will not reliably be reflected in other instances.

Suggested Solution

The DbContext could be encapsulated, with the test base exposing only an AddEntity method and a Query method.

Acceptance Criteria

Acceptance Criteria defines the requirements that must be met for the story to be completed. This is WHAT must be done.

See https://www.ssw.com.au/rules/acceptance-criteria.

1. When I write unit tests and integration tests, existing test examples are clear and I can replicate them and get expected test outcomes
2. Shared or common classes do not expose properties or methods that could allow me to write tests in a way that does not align with our intended best practice
3. The testing apparatus guides me into the pit of success

Tasks

Tasks help developers to track small bits of work needed to meet the ACs. This is HOW the work will be done.

- [ ] Propose alternative solutions/approaches
- [ ] Discuss with SAW team
- [ ] (if applicable) implement proposed changes

Thanks!

Start by locating the shared integration-test base, its DbContext injection, and existing test examples. Compare exposing only AddEntity and Query with current usage, then discuss alternative approaches with the SAW team. Done means test examples remain clear and predictable while common test classes prevent access patterns that bypass intended practices.