我正在尝试使用我最近正在研究的项目进行单元测试。
它涉及一个SQL Server 2008 R2数据库和一个使用C#、. NET 4.5和Visual Studio 2013 Premium的WCF服务。我们使用实体框架(EF)6.0.1。
我正在尝试使用Microsoft Fakes单独测试WCF,以便不需要数据库。我们的目标是使用“内存数据库”来做到这一点。我的困难是为EF的dbcontext“存根”,所以我知道它处于已知状态,可以查询,更改和监视。
我已经读过,这可能是一个坏主意,因为linq-to-objects与linq-to-sql之间的Linq提供程序不同。该功能可以在编译时通过,但在运行时失败。为了解决这个问题,一旦通过TFS部署到我们的DEV服务器,我们还进行了集成测试(将WCF连接到真实数据库)。
我还读过有关dbcontext可以使用MS FAKES填充的信息,但感觉很不对。
另外,添加存储库模式(依赖注入(DI))不会导致我们的代码覆盖率增加,这是我们期望的结果之一。
然后,我发现了这篇文章http://msdn.microsoft.com/en-gb/data/dn314429.aspx和这篇文章http://frankdecaire.blogspot.co.uk/2013/11/entity-framework-6-mocking -and-unit.html?showComment = 1392224065716
这实现了我想要做的,但是使用了Moq。可以将此代码从Moq转换为MS FAKES吗?FAKES是否能够完成Moq所做的一切,还是我也应该学习Moq以增加我对FAKES的有限了解?
var mockSet = new Mock<DbSet<account>>();
mockSet.As<IQueryable<account>>().Setup(m => m.Provider)
.Returns(data.Provider);
mockSet.As<IQueryable<account>>().Setup(m => m.Expression)
.Returns(data.Expression);
mockSet.As<IQueryable<account>>().Setup(m => m.ElementType)
.Returns(data.ElementType);
mockSet.As<IQueryable<account>>().Setup(m => m.GetEnumerator())
.Returns(data.GetEnumerator());
有任何问题请随时询问我(们
干杯
凯尔
IMO,您需要通过采用更分层的方法来开始将代码解耦。我不太确定通过隔离测试WCF需要实现什么。我建议进行三层测试,如下所示:
数据访问-使用EF及其数据库上下文并实现数据访问接口。您应该对此进行单元测试,而不模拟EF的数据库上下文。此层的测试将取决于“状态”。我的意思是,您的测试将使用真实数据和数据库进行CRUD操作。您只需要确保在测试运行后不要将更改持久保存到数据库。可以使用Spring.Net的测试库来实现此目的,或者只是在事务范围内运行测试,然后在每次测试运行后回滚事务(在清理过程中)。
业务逻辑-包含业务逻辑并与数据访问接口一起使用。使用任何DI框架(例如spring.net或ms unity)注入数据访问层。您应该通过避免实际的数据库调用来对此进行单元测试。这是NMock,Rhinomock或MOQ出现的地方。使用模拟设置边界条件和异常条件,并确保您的业务逻辑解决了所有问题。
WCF服务层-与您一起进行操作和数据合同。理想情况下,仅将呼叫转发给业务逻辑,并将响应转换为数据合同。我更喜欢在此级别进行两种类型的测试:a)用于测试翻译和适当的呼叫转移的单元测试。b)很少使用代理进行基本的集成测试,而一些测试数据无需进行任何模拟就可以遍历整个堆栈。
我对MS假货唯一的问题是,它随VS2012最终版本一起提供,因此与MOQ之类的东西相比,其用户群要少得多。
本文收集自互联网,转载请注明来源。
如有侵权,请联系[email protected] 删除。
我来说两句