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.
When I write unit tests and integration tests, existing test examples are clear and I can replicate them and get expected test outcomes
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
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
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
AddEntitymethod and aQuerymethod.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.
Tasks
Tasks help developers to track small bits of work needed to meet the ACs. This is HOW the work will be done.
Thanks!