为什么写本文

当团队有要求写Unit Test时，你是不是想坚持团队的这种要求，但是内心中会有一下几种想法呢？

1，我该怎么开始Unit Test ?
2，我写代码似乎没有什么该测试的?
3，感觉写Unit Test会花费我部分时间?
4，参考别人的Unit Test Code，并不清楚为人为什么写那么多Unit Test，到底该测试什么？
...

如果你被这些问题困扰，可以看看本文，或许能给一些答案。

---

概要

0, 哪些场景需要Unit Test
1，为API接口添加测试
2，业务代码如何测试
3，Exception的测试
4，断言的风格

---

0，哪些场景需要Unit Test

时间和质量总是被开发人员、开发人员周围的角色所提及，你或许知道“测试金字塔”，但是这里并不是讲测试金字塔中的策略，而是实际工作中如何权衡写UnitTest的时间和质量。

衡量时间和质量，可以通过一个很好的纬度的权衡：价值。

围绕价值，我们没有必要处处写测试这么极端，也不用完全觉得写Unit Test花费了太多时间。

在产出价值最大的地方花时间加上Unit Test，投入产出比才会最大化（即：价值最大化）。

以Java Web后端开发为例，以下几部分是非常值得我们关注的。

1，API是否符合预期
2，业务实现是否符合预期
3，程序中Exception是否已经捕获处理

1，为API添加测试

为什么为API添加测试？

1，API是Web服务与外界直接沟通的地方，确保API能够接收预期的参数并返回预期的结果，保证API的正确性。
2，为API添加UnitTest能够降低调用API是出现异常情况的沟通成本。

应该为API添加哪些测试？

1，验证参数
2，验证返回结果

如何写API的测试？API测试示例

---

2，业务代码的测试

为什么为业务代码添加测试?

1，证明自己的业务逻辑是对的，相比程序的整个上下文都运行起来后实际测试才发现问题，发现/修改的成本更低。
2，修改代码是，原来写的业务Unit Test成了约束，修复Unit Test的过程，是我们确认自己程序修改正确的过程。

为业务代码添加哪些测试？

1，当调用某段业务代码后，有没有返回预期的的想要的结果
2，当业务代码传入一些非法数据是，业务代码是否返回了期望的结果

如何进行业务逻辑的测试？业务逻辑的测试示例

---

3，Exception的测试

为什么添加Exception的测试？

1，关注Exception能够让我们写的代码更加健壮，确保业务代中的Exception早在掌握之中。
2，关注Exception让我们多重视角看待需求，不仅仅正常的情况下程序正常运行，也应该保证异常情况是程序是否能够正常运行，返回预期的结果。

为Exception添加哪些测试

1，当某些异常情况下，是否抛出期望的异常；
2，当抛出异常时，是否期望的代码执行时抛出的异常。

如何对Exception进行测试？Exception测试示例