Constrain on IDbContext instead of DbContext for easier unit testing and mocking

[benjaminramey]

Because the TDbContext generics are constrained with where TDbContext : DbContext, I have to call all the relevant methods with concrete class types. This makes for more difficult unit testing because I will eventually have to mock a concrete DbContext class somewhere.

If we instead constrain on the new IDbContext that only defines methods that the library needs (and DbContext already implements), then I can inherit this interface on my DbContext interfaces and mock much easier.

This is a breaking change, of course, because any client code that would upgrade to this change would need to implement the IDbContext interface on all their client DbContexts.

[thorhj]

Is there any chance for this to supported at some point? I too am having difficulty with unit testing because the IAmbientDbContextLocator.Get method is not constrained on an interface.

[Drizin]

I also wonder why this wasn't incorporated. I'm using this interface with Fake Contexts (generated using https://github.com/sjh37/EntityFramework-Reverse-POCO-Code-First-Generator ) and it's working fine.