Question

我正在使用TDD，一切顺利。当我到达我的实际存储库时，虽然我不知道如何测试它。

考虑下面的代码 - 这就是我知道我想写的内容，但是如何在不进行集成测试的情况下以测试方式解决这个问题。

public class UserDb : IUserDb
{
    public void Add(User user)
    {
        using (var context = new EfContext())
        {
            context.Users.Add(user);

            context.SaveChanges();
        }
    }
}

forsvarir下面的链接是我想要的答案。我怎么能这样做？

http://romiller.com/2012/02/14/testing-with-a-fake-dbcontext/

Answer 1

您希望通过测试第三方工具来实现什么目标？您可以模拟上下文var fakeContext = A.Fake<IDbContext>();，然后断言尝试写入数据库。 A.CallTo(() => fakeContext.SaveChanges()).MustHaveHappened();

以上示例使用FakeItEasy模拟库。

Answer 2

这类问题的通常答案是：

隔离难以测试的依赖项（EF上下文）
在测试中提供虚假实现以验证SUT的正确行为

当你在被测系统中测试有趣的逻辑时，这一切都有意义。对于您的特定情况，存储库看起来像是干净域和EF感知逻辑之间的非常薄的抽象。很好，保持这种方式。这也意味着它并没有真正做很多工作。我建议你不要费心去编写单独的单元测试（包装EF DbContext似乎是额外的工作，可能不会减轻它的重量）。

请注意，我并不是说您不应该测试此代码：我经常倾向于使用真实数据库测试这些精简存储库，即通过集成测试。然而，对于使用这些存储库的所有代码，我会通过向被测系统提供虚假存储库来坚持孤立的单元测试。这样我就可以覆盖我的存储库代码并测试EF实际上是以正确的方式与我的数据库通信，并且间接使用这些存储库的所有其他测试都很好，隔离且闪电般快。

单元测试实体框架存储库

2 个答案: