我目前正在开发一个我们公司从以前的承包商那里获得的项目，并且它在测试覆盖率方面处于非常糟糕的状态 - 几乎没有测试，代码库非常纠结和脆弱，所以任何小的变化很可能以最复杂和最令人惊讶的方式打破一切。
为了解决很多问题，我们将开始一个新项目，并且我想阻止团队从旧项目继承糟糕的文化，因为诱惑做“快速和肮脏”的事情会太棒了。
所以，我想通过某种方式自动执行TDD，或多或少地通过服务器端git钩子强制执行正确的代码风格。
就我而言，我的想法是创建一个服务器端推送钩子，它将作用于 OLD 提交（例如推送前的分支HEAD），以及 NEW 提交（推送后的分支HEAD）大致如下：
首先，将代码中的更改与测试中的更改分开。如果测试位于单独的文件夹中，这应该很容易。
确定新的或已更改的测试列表。
在 OLD 代码上的 NEW 提交中运行新的和更改的测试。断言所有这些测试都应该是红色的。如果任何测试为绿色，则表示这些测试无效或冗余，因为测试功能尚不存在。
从 NEW 代码上的 NEW 提交运行新的和更改的测试，捕获代码覆盖率。断言所有测试都是绿色的。断言 NEW 代码中的至少所有新行和更改行都包含在测试中。
在 NEW 代码上运行所有测试，以检查回归，捕获代码覆盖率。断言所有测试都是绿色的，并且代码覆盖率已经完成。之前运行一小部分测试的关键是抽烟测试。完整的套件可能需要几分钟的时间才能运行，几乎没有更改过的测试会立即运行。
我也可以将这些测试内容作为本地钩子提供，只需测试本地头部和远程头部之间的区别，而不必尝试推送可能损坏的代码。
这有什么意义，还是我错过了什么？另外，我是在重新发明轮子，还是有任何最佳实践来强制执行这样的事情，如果“我们都同意这里的成年人”并不属于这种情况吗？
答案 0 :(得分：1)
这有什么意义，还是我错过了什么？
如上所述，这让我觉得这是一个可怕的想法。
我预见到两个问题：
首先，您的测量正在对严格模式下的测试引入做出强有力的假设，而且测试的假设一般都不明显。
其次，这个过程并不能帮助开发人员，而是阻止了开发人员，除非你在假设情况下做出的假设适合当前不可预见的情况。
您可以查看Greg Young的演讲Stop Over Engineering;我们工具的目标并不是强迫团队在所有情况下都做一件事。我们的目标应该是在易于理解的环境中使事情变得更容易，并在特殊情况下避免使用。
现在，如果你稍微改变一下，你可能会有一些有趣的事情发生。如果您要对所有提交应用相同的度量，跟踪结果而不阻止流程，那么您需要定期查看很多非常有趣的信号。在那时，您可以了解违反政策的频率，违规行为的频率，甚至可能是对团队成本的估计。
换句话说，您可以花时间优化政策并衡量其有效性，然后在所有情况下强制执行。
对于您的政策未涵盖的案例，git commit --no-verify可能是一个充分的逃脱舱口。
答案 1 :(得分：0)
如果您想改善团队文化，请提出在团队层面发挥作用的内容。
为什么测试套件通常作为持续集成构建的一部分执行是有原因的。源控件挂钩仅对提交的开发人员可见，而构建是每个人都关心的。任何团队成员都可以选择破坏的构建并修复它，从而最大限度地提高解决问题的机会。
- 在OLD代码的新提交中运行新的和更改的测试。断言 所有这些测试都应该是红色的。如果任何测试是绿色的，这意味着 这些测试无效或冗余，因为经过测试 功能尚不存在。
或许它确实如此。您如何区分重构测试和Assert更改的测试之间的区别？在新要求和之前隐含存在的要求之间，我们只考虑稍后进行测试？
- 断言 至少新代码中的所有新行和更改行都包含在内 测试
100％的测试覆盖率是一种嵌合体。应该追求的最终目标，但如果没有达到目标，就不能阻止你的行为并咬你。
你的意图是正确的，但我不相信委托自动机应该是一个好主意，更不用说通过技术笨重和维护沉重的手段。