单元测试实体框架存储库
本文关键字:存储 框架 实体 单元测试 | 更新日期: 2023-09-27 17:50:20
我正在使用TDD,一切都很顺利。当我到达我的实际仓库时,虽然我不知道如何测试它。
考虑下面的代码-这是我知道我想写的,但我如何在不进行集成测试的情况下以测试优先的方式解决这个问题。
public class UserDb : IUserDb
{
public void Add(User user)
{
using (var context = new EfContext())
{
context.Users.Add(user);
context.SaveChanges();
}
}
}
下面由forvarir提供的链接就是我想要的答案。我怎么能做到呢?
http://romiller.com/2012/02/14/testing-with-a-fake-dbcontext/这类问题通常的答案是:
- 隔离难以测试的依赖项(EF上下文)
- 在测试中提供一个伪实现,以验证SUT的正确行为
当您在被测系统中有有趣的逻辑要测试时,这一切都是有意义的。对于您的特定情况,存储库看起来像是一个非常薄的抽象,介于干净的域和ef感知逻辑之间。很好,保持这种状态。这也意味着它实际上并没有做多少工作。我建议您不要费心编写独立的单元测试(包装EF DbContext似乎是额外的工作,可能无法发挥其作用)。
请注意,我并不是说你不应该测试这些代码:我经常倾向于使用真实的数据库来测试这些瘦存储库,也就是通过集成测试。然而,对于使用这些存储库的所有代码,我坚持通过向被测系统提供假存储库来进行独立的单元测试。这样我就覆盖了我的存储库代码和测试,EF实际上以正确的方式与我的数据库通信,所有间接使用这些存储库的其他测试都很好,隔离和快速。
您希望通过测试第三方工具实现什么?您可以模拟上下文var fakeContext = A.Fake<IDbContext>();
,然后断言尝试向数据库写入。A.CallTo(() => fakeContext.SaveChanges()).MustHaveHappened();
上面的例子使用了FakeItEasy模拟库