Using Test Doubles with DbEntityEntry and DbPropertyEntry

dbcontext entity-framework-6 moq testing


I'm using VS2013 with Moq & nUnit and the new Test Doubles in EF6 as described in this is from MSDN. Everything was OK until I had to take this action:

var myFoo = context.Foos.Find(id);

after that:

myFoo.Name = "Bar";

after that:

context.Entry(myFoo).Property("Name").IsModified = true;

This is where I encounter a problem:

Additional information: Member 'IsModified' cannot be called for property 'Name' because the entity of type 'Foo' does not exist in the context. To add an entity to the context call the Add or Attach method of DbSet.

Although I can see all the items I added before running the test when I look at the "Foos" in the context with an AddWatch. They are thus present.

I took the FakeDbSet (or TestDbSet) from the paper and made it. At the constructor, where each FakeDbSet is initialized, I place it in the FakeContext. akin to this

Foos = new FakeDbSet<Foo>();

I want to know if it's possible to use the FakeDbSet and the FakeContext in the test doubles scenario so that the test double can access the DbEntityEntry and DBPropertyEntry. Thanks!

11/12/2014 8:14:34 PM

Accepted Answer

I can see all items I Add'ed before running the test. So they are there.

In actuality, you've only added things to anObservableCollection . Thecontext.Entry approach is much more complex than that. In order to actively add, alter, and remove entities, a change tracker is required. To mock this change tracker, use theObjectStateManager Good luck (ignoring the fact that it's not intended to be laughed at at all)! More than 4000 lines of code are present.

Sincere to God, I find it confusing that so many blogs and articles insult EF. The only thing that should deter it should be the many LINQ to objects and LINQ to entities have different characteristics.. These fictitious situationsDbSet s create a brand-new cosmos that contains bugs all on its own. I've made the decision to just perform integration tests when and where EF is incorporated into my project. I have a strong sense that everything is fine when I run a working end-to-end test. A unit test that simulates EF does not. Don't get me wrong; some do).

But supposing you still want to engage in mockingDbContext.Entry<T> Sadly, it's impossible.

  • The process isn't virtual.
  • It provides aDbEntityEntry<T> , a class that wraps an internal constructor around anInternalEntityEntry which is a class within. And, incidentallyDbEntityEntry doesn't put an interface into place.

So, in response to your query

is it possible to (...) have access to DbEntityEntry and DBPropertyEntry from the test double?

No, EF's mocking hooks are merely quite superficial, and you'll never even approach understanding how EF truly functions.

5/23/2017 12:01:54 PM

Popular Answer


Related Questions


Licensed under: CC-BY-SA with attribution
Not affiliated with Stack Overflow
Licensed under: CC-BY-SA with attribution
Not affiliated with Stack Overflow