推荐这本 20 年出版 “Unit Testing: Principles, Practices, and Patterns”。这本书里会讲得比较“务虚”，但可能恰恰可以解决单元测试实施的部分问题，作者开始便强调没有必要为所有代码编写单元测试，那么如果确定需要为哪些代码编写单元测试呢？作者提出了关于好的单元测试四要素的定义，在其中作者给出了他的答案。

1. Protection against regressions
其中关于 regression 作者给出的解释为 “一个功能在一些代码改造后不再按预期工作”
关于如何评判单元测试是否满足这点，可以从3个方面考虑：
a: The amount of code that is executed during the test：概括来就是如果一个方法/函数涉及很多代码行数非常多，那么有必要为其编写单元测试，因为 “code is not an asset, it's a liability” （代码不是资产，而是负债），因为随着代码量的增长，相应的系统问题也会越多。
b: The complexity of that code：如果代码的复杂度较高，那么也需要为其编写单元测试。
c: The code's domain significance：单元测试所覆盖的代码要具有具体的业务语意。

2. Resistance to refactoring
好的单元测试应当满足，当其覆盖的应用程序代码完成重构后不会测试失败。对应的令人沮丧的是，当我们完成代码重构后，满足所有功能测试与验收，唯一无法通过此前编写的单元测试......

3. Fast feedback
测试一定要是能够快速执行的，似乎没什么好特殊说明的。

4. Maintainability
单元测试也需要考虑维护成本，好的单元测试代码也一定是易于理解的，容易修改的，请把单元测试同样作为一等公民。
展开
HAibiiin于2024-12-23 06:25发布的图片
今日新鲜事
avatar
赞过
评论
相关推荐