揪心疑惑
在撰写单元测试的过程中，你是否曾经被以下问题困扰过？
- 为什么要写单元测试？单元测试的目标是什么？
- 单元测试的粒度是怎样的？什么叫单元？a class, a function, or a behavior, or an observable behavior?
- 单测覆盖率真的有用吗？有什么用？又有哪些限制？
- 怎样才能写好单元测试？怎样才能写出性价比最高的单元测试？
- 如何判断一个单元测试的好坏？有没有具体可供参阅的维度？
- 哪些代码需要写单元测试，哪些代码没必要写单元测试？
- 单元测试和集成测试的边界是什么？
- （单元丨集成）测试到底是要测什么东西？
- 单元测试的侧重点是什么？集成测试的侧重点是什么？二者的比例该是怎样的？
- 如何使用 Mock？哪些东西是需要 Mock 的？哪些东西是不应该 Mock 的？需要 Mock 的东西，应该在哪个层次进行 Mock？（你的 repository 层需要 Mock 吗？）
- 为什么你的测试代码很脆弱，总是需要频繁修改，维护起来难度很大？
- 如何减少测试结果的假阳性和假阴性？
四根柱子
对于第 5 个问题，作者提出了 4 个维度：
- Protection against
regressions：防止回归，通过自动化验证代码修改后原有功能不受破坏。
- The amount of code that is executed during the test.
- The complexity of that code.
- The code’s domain significance.
- Resistance to
refactoring：抗重构性，重构业务代码时，测试代码无需过多变动便可通过用例，证明重构无误。
- Tests provide an early warning when you break existing functionality.
- You become confident that your code changes won’t lead to regressions.
- Fast feedback：快速反馈。
- Maintainability：可维护性。
- How hard it is to understand the test.
- How hard it is to run the test.
对于这 4 个问题，你是否又有以下疑问：
- 哪个维度是最重要的？
- 怎样才能写出满足各个维度的测试代码？
- 如果维度之间存在矛盾，如何 trade off？
