提交没有人使用的代码是一个不好的主意，因为审阅者很难理解为什么要编写代码，并且很难知道代码是否正确。
就像我在TDD中编写代码一样，在编写代码逻辑之前，我还要编写单元测试。
测试有时依赖于新的模拟，它们的第一个（也是唯一一个）用途是测试。应用上述原理，我不想自己提交模拟。因此，我最终在同一提交中提交了单元测试和模拟。
这使提交相当长，并且模拟感觉不像它的一部分。让它们处于不同的提交会更好得多（甚至可以让另一个开发人员来审查它，因为它可以更好地理解模拟代码）。
我知道这个设计问题可能只是一个口味问题，但是我对TDD还是陌生的，因此我觉得可能有一个解决方案比另一个解决方案更正确。
任何输入将不胜感激。
答案 0 :(得分：3)
关于Git提交的最重要政策是每次提交都应通过构建。有人可能会争辩说，使用TDD，有必要执行红色/绿色/重构周期的每个步骤，如下所示：
但是，如果您提交红色，则提交将使构建失败，这将很好地利用例如git bisect是不可能的。我认为，可以根据需要在 green 和 refactor 阶段之外进行单独的提交，但是如果可以将每个总体更改保持在很小的范围内，则不是最重要的。
如果您可以在添加测试之前添加模拟，并且构建仍然可以通过，那么我认为这是可以接受的做法。这不是我自己要做的事情，但我不认为这将是一个问题。
通常，审阅者将查看多个提交的组合差异，因此这不太可能造成混淆。
仍然，对于TDD，最常见的过程是首先编写测试，然后编写恰好足以使测试通过的代码。如果其中包含模拟，则将它们添加为对测试的反应。
如果您发现它使某些粗粒度的提交成为可能，那么这就是TDD流程，可以为您提供反馈。反馈并不是说您的流程应用程序一定是错误的，而是您可能会从重新考虑API设计中受益。