Is the feature request related to a problem
It seems the verify entityframework library is not usable in tests with a webapplicationfactory. We write integration tests against a webapplicationfactory (https://docs.microsoft.com/en-us/dotnet/api/microsoft.aspnetcore.mvc.testing.webapplicationfactory-1?view=aspnetcore-5.0) to test our complete backend. During setup of the factory, we register our entityframework dbcontext as a singleton, so that we have the same instance outside of the test as inside the test call.
It seems that the verify entityframework library uses asynclocal to record all actions on the dbcontext. This has the final result that the recorded actions inside the api call are not available (and thus verifiable) in the integration test.
Describe the solution
Possibly an option / feature flag that the changes on the dbcontext are not recorded on an asynclocal variable, but just a normal (static) variable. This will not work in all scenario's where the library is currently used, but the extra option would enable the library to be used in the webapplication factory scenario.
Describe alternatives considered
We have considered the verify sqlserver library, however the verification of individual sql statements is too low level for us and would not be maintanable / verifiable for us in the long term.
Is the feature request related to a problem
It seems the verify entityframework library is not usable in tests with a webapplicationfactory. We write integration tests against a webapplicationfactory (https://docs.microsoft.com/en-us/dotnet/api/microsoft.aspnetcore.mvc.testing.webapplicationfactory-1?view=aspnetcore-5.0) to test our complete backend. During setup of the factory, we register our entityframework dbcontext as a singleton, so that we have the same instance outside of the test as inside the test call.
It seems that the verify entityframework library uses asynclocal to record all actions on the dbcontext. This has the final result that the recorded actions inside the api call are not available (and thus verifiable) in the integration test.
Describe the solution
Possibly an option / feature flag that the changes on the dbcontext are not recorded on an asynclocal variable, but just a normal (static) variable. This will not work in all scenario's where the library is currently used, but the extra option would enable the library to be used in the webapplication factory scenario.
Describe alternatives considered
We have considered the verify sqlserver library, however the verification of individual sql statements is too low level for us and would not be maintanable / verifiable for us in the long term.