git - 使用服务器端 Hook 实现 TDD 的红/绿/重构文化

Question

背景(可选)

我目前正在从事我们公司从以前的承包商那里得到的一个项目，它在测试覆盖率方面处于非常糟糕的状态——几乎没有测试，代码库非常复杂和脆弱，所以任何小的改变很可能以最复杂和令人惊讶的方式打破一切。

为了解决许多问题，我们将开始一个新项目，我想防止团队从旧项目中继承不良文化，因为这样做会带来“快速而肮脏”的诱惑足够好。

想法

因此，我考虑了一些自动执行 TDD 的方法，这或多或少类似于人们通过服务器端 git Hook 执行正确代码风格的方式。

在我的例子中，想法是创建一个服务器端推送 Hook ，它将作用于 OLD 提交(例如，在推送之前分支 HEAD)和 NEW 大致按照以下方式提交(推送后的分支 HEAD):

• 首先，将代码更改与测试更改分开。如果测试位于单独的文件夹中，这应该很容易。

• 确定新的或已更改的测试列表。

• 在 OLD 代码上从 NEW 提交运行新的和更改的测试。断言所有这些测试都应该是红色的。如果任何测试是绿色的，这意味着这些测试无效或多余，因为测试的功能尚不存在。

• 在 NEW 代码上从 NEW 提交运行新的和更改的测试，捕获代码覆盖率。断言所有测试都是绿色的。断言至少 NEW 代码中所有新的和更改的行都被测试覆盖。

• 对新 代码运行所有测试以检查回归，捕获代码覆盖率。断言所有测试都是绿色的，并且代码覆盖是完整的。早期只运行一小部分测试的目的是冒烟测试。完整套件可能需要整整几分钟才能运行，而很少有更改的测试几乎可以在瞬间运行。

对我来说，将这些测试内容也作为本地 Hook 提供也很有意义，只需测试本地头和远程头之间的区别，而不必尝试推送可能损坏的代码。

这有意义吗，还是我遗漏了什么？另外，如果“我们在这里都是同意的成年人”不是真的，我是在重新发明轮子，还是有任何最佳实践来执行这样的事情？

Answer 1

Does this make any sense, or am I missing something?

如前所述，这让我觉得这是一个可怕的想法。

我预见到两个问题:

首先，您的测量是根据严格的模式对测试的引入做出强有力的假设，而测试的假设是否普遍成立一点也不明显。

其次，该过程不会协助开发人员，而是会阻碍开发人员，除非您放入 Hook 的假设即使在当前不可预见的情况下也适用。

您可能会回顾 Greg Young 的演讲 Stop Over Engineering ;我们工具的目标不是强制团队在所有情况下都以唯一正确的方式做事。目标应该是在易于理解的情况下让事情变得更容易，并在特殊情况下远离障碍。

现在，如果您稍微改变一下，您可能会有一些有趣的事情发生。如果您要对所有提交应用相同的度量，跟踪结果而不阻塞流程，您将有很多非常有趣的信号需要定期审查。到那时，您就会了解违反政策的频率、这些违规的频率，甚至可能估计团队的成本。

换句话说，您可以花时间完善政策并衡量其有效性，然后再强制执行所有情况。

git commit --no-verify对于您的保单未涵盖的情况，这可能是一个足够的逃生 channel 。