为单元测试编写模拟是否应该在单独的提交中？答案

【问题标题】：Should writing mocks for unit tests be in a separate commit?为单元测试编写模拟是否应该在单独的提交中？
【发布时间】：2020-06-18 11:13:31
【问题描述】：

提交没有人使用的代码是个坏主意，因为审阅者很难理解为什么要编写它，也很难知道代码是否正确。

正如我在 TDD 中编写的那样，在编写代码逻辑之前，我会编写单元测试。
测试有时依赖于新的模拟，它的第一个（也是唯一的）使用是测试。应用上述原则，我不想自己提交模拟。因此，我最终在同一个提交中提交了单元测试和模拟。

这使得提交变得相当长，并且模拟并不像是其中的一部分。将它们放在不同的提交中会好得多（甚至可能让不同的开发人员对其进行审查，以便更好地理解模拟代码）。

我知道这个设计问题可能是个人喜好问题，但我是 TDD 新手，感觉可能有一种解决方案比另一种更正确。
任何输入将不胜感激。

【问题讨论】：

【解决方案1】：

关于 Git 提交的最重要政策是每个提交都应该通过构建。有人可能会争辩说，使用 TDD，提交红/绿/重构周期的每个步骤是有意义的，如下所示：

但是，如果您在红色上提交，您将有提交失败的构建，这将充分利用例如git bisect不可能。我认为如果您愿意，可以在 green 和 refactor 阶段进行单独的提交，但是如果您可以将每个整体更改保持在很小的范围内，那么这并不是最重要的。

如果您可以在添加测试之前添加模拟，并且构建仍然通过，我认为这是可以接受的做法。这不是我自己会做的事情，但我不知道这会是什么问题。

通常，审阅者会查看多个提交的组合差异，因此这不太可能造成混淆。

不过，对于 TDD，最常见的过程是首先编写测试，然后编写足够的代码以使测试通过。如果其中包括模拟，则将它们添加为对测试的反应。

如果您发现它会导致一些粗粒度的提交，那么这就是 TDD 过程为您提供反馈。反馈并不是说您对该流程的应用一定是错误的，而是您可能会从重新考虑您的 API 设计中受益。

【讨论】：

重新考虑 API 设计是什么意思？如果我有一个简单的 API，它包括一个需要将值写入本地数据库的函数。然后在为函数编写测试时，我需要向数据库添加一个模拟。由于函数签名需要获取一个 DB，调用它的测试需要给它一个实现完整 DB 接口的对象。这是很多代码，即使 DB API 中的大多数函数的实现都不做任何事情。
@NimrodFiat 够公平的。我不知道你会考虑什么很多代码。然而，也许完整的数据库界面 是一个线索。那是一个胖接口吗？是提前给的吗？如果是这样，为什么？如果您遵循 TDD，则在测试将其变为现实之前，您不会编写生产代码。它有助于遵循 SOLID 原则。 DIP 表示客户端代码拥有接口，ISP 建议保持接口窄。因此，如果您需要保存到数据库，请为此定义一个方法，并使用该方法创建一个 Mock。
有道理。我的界面太大了。谢谢。