将测试双打与DbEntityEntry和DbPropertyEntry一起使用

Question

我在MSDN中使用了EF6中新的测试双打.VS2013与Moq和nUnit.一切都很好,直到我不得不这样做:

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

然后:

myFoo.Name = "Bar";

然后 :

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

此时是我收到错误的地方:

附加信息:无法为属性"名称"调用成员"IsModified",因为上下文中不存在"Foo"类型的实体.要向上下文添加实体,请调用DbSet的Add或Attach方法.

虽然,当我用AddWatch检查上下文中的'Foos'时,我可以在运行测试之前看到我添加的所有项目.所以他们在那里.

我从文章中创建了FakeDbSet(或TestDbSet).我将每个FakeDbSet放在构造函数中的FakeContext中,每个构造函数都被初始化.像这样:

Foos = new FakeDbSet<Foo>();

我的问题是,是否可以使用测试双精度场景使用FakeDbSet和FakeContext,以便从测试双重访问DbEntityEntry和DBPropertyEntry？谢谢!

Answer 1

在运行测试之前,我可以看到我添加的所有项目.所以他们在那里.

实际上,您只是添加了一个项目ObservableCollection.该context.Entry方法比这更深入.它需要更改跟踪器积极参与添加,修改和删除实体.如果你想模仿这个改变跟踪器,ObjectStateManager(忽略它根本不被设计为嘲笑的事实),祝你好运!它有超过4000行代码.

坦率地说,我不了解所有这些关于嘲笑EF的博客和文章.LINQ to objects和LINQ to entites之间的众多差异应该足以阻止它.这些模拟上下文DbSet构建了一个全新的宇宙,它本身就是一个漏洞的来源.我决定只在我的代码中涉及EF的时间和地点进行集成测试.一个有效的端到端测试让我感觉事情还可以.单元测试(伪造EF)没有.(其他人这样做,不要误会我的意思).

但是我们假设你还想冒险进行嘲弄DbContext.Entry<T>.太糟糕了,不可能.

• 该方法不是虚拟的
• 它返回一个DbEntityEntry<T>带有内部构造函数的类,它是一个包装器InternalEntityEntry,它是一个内部类.顺便说一下,DbEntityEntry没有实现一个接口.

所以,回答你的问题

是否有可能(...)从测试双重访问DbEntityEntry和DBPropertyEntry？

不,EF的嘲笑钩子只是非常肤浅,你甚至都不会接近EF真正的作用.