Question

我在这里看到了类似的问题，我想我得到了人们回答的方向，但我需要确认是否应该使用Stubbed存储库为我的解决方案创建纯单元测试。

如果我有以下单元测试（使用Microsoft的假装配和MSTest创建）：

 [TestMethod]
 public void creating_user_returns_a_valid_id()
 {
     var userId = new Random().Next(1, 1000);

     var userRepository = new StubIDataEntityRepository<User>
     {
         CreateT0 = x =>
             {
                 return userId;
             }
     };

     var user = new User();

     var result = userRepository.CreateT0(user);

     Assert.AreEqual(result, userId);
 }

现在，我一直在研究单元测试，我明白纯单元测试不能跨越任何边界或责任，因此Stub。我知道，如果我想测试在我的数据库中创建用户确实转换了有效的用户ID，我需要创建一个集成测试。那么，我在这里测试的确切是什么？我知道人们说应用程序逻辑，这一切都非常有效，但我确实创建了一个创建id的测试，告诉假存储库从其Create方法返回该Id，然后确认从Create方法返回的Id是相同的值。感觉我正在为基本上如下的工作做很多工作：

x = 1，y = 1，assert.areequal（x，y）!!

答案真的是培训开发人员通过TDD设计代码吗？如果你们中的任何一位TDD大师都可以启发我，那将非常感激！

亲切的问候

本

Answer 1

你没有在这里测试任何有用的东西。

每个单元测试都有一个所谓的系统测试（SUT）。那是你要测试的课程要测试SUT，你不能嘲笑它，因为你要测试模拟，而不是SUT。这有点毫无意义。

在您的情况下，您似乎想要测试存储库，但您也在模拟存储库，使测试毫无意义。

您希望在测试中使用模拟存储库，其中SUT是另一个使用存储库的类。

测试存储库很可能是集成测试的任务。直接访问数据库的存储库方法无法通过单元测试进行测试。

Answer 2

通过“嘲弄”或“抄袭”您的数据访问，您可以确保单元测试完全评估代码的性能。使用模拟，你知道完全在被调用时将返回什么数据，以及它应该采用什么格式。您可能不是唯一一个写入您的数据库或数据文件的人，因此您的测试结果可能会略有不同，让您感到头疼。

在流程工业中，这个概念被称为隔离测试，它可以更好地感知（IMHO）人们在单元测试中想要实现的目标。当你刚刚开始一个项目时，你所说的“做大量工作”是有效的，但项目复杂性是一种熵形式：只有你运行它的时间越长，它就越糟糕。尽早进入良好实践可以为您节省一些调试噩梦。

希望有所帮助：）

Answer 3

这个问题很精致......我的回答是，如果你的鼻子闻起来有些可疑，可能就是这样。

如果您的应用程序与数据库接口，您应该将数据库访问权委托给一个角色（通常称为XXXRepository），其中XXX是要保留的资源类型（例如，客户）。

现在，如果您想测试XXXRepository的实现，您应该编写集成测试（即验证应用程序的其余部分与数据库子系统集成的测试）。换句话说，是否符合合同条款（XXXRepository）。因此，名称'合同测试'。
如果您正在测试“应用程序的其余部分”中的代码，那么您应该编写单元测试并模拟XXXRepository角色，这是出于隔离和速度的原因。

简单地说，如果您的SUT负责写入文件 - 您的测试应该调用SUT方法并验证文件是否相应地更改。还有别的......我们以后只会为惊喜做好准备。

使用Fake / Stub存储库创建单元测试有什么意义

3 个答案: