State Interceptor Tests #118
Conversation
|
@luboshl Let me know what you think of how I refactored some of the tests to use InlineData instead of ClassData. The idea is that the tests only cover scenarios which are specific to the test. Hopefully the changes are OK. 😄 |
|
I found a bug. 🐛 See commit f36fcda. There are places where the interceptors are not being called because TE is not responsible for setting entity state because EF is setting the state automatically. For example, in 1-1 and 1-M relations, TE is not setting the child state when a parent has been set to Added. In this case EF is setting the child state to Added, so TE does not need to set it. However, we will still want to call the interceptors. |
|
@luboshl Have a look at this now. I've completed the test refactoring by replacing ClassData with InlineData. If everything is OK, I can squash and merge. |
|
Everything ok! |
- Allows user to intercept DbContext.ApplyChanges in order to specify the EntityState which should be applied to one or more entities. - Resolves issue #106.
|
It looks good 👍 |
tonysneed
force-pushed
the
luboshl-iss106-tests
branch
from
0f0ba16
to
9938cb7
Compare
|
Thanks @luboshl for all your hard work on this feature! |
Continuation of #117. I am refactoring tests to use InlineData instead of ClassData, because it is easier to view the test as a specification and because we only need to test branches in
ApplyChangeswhere the interceptors are called or should be called.