单元测试实战训练营-培训总结

培训的本质，不在于记住哪些知识，而是在于它触发了你的多少思考。一旦我们开始反思我们的工作，工作将会不再一样。 ----- 哈佛大学 <正义> Sandel教授

之前也参与过刘讲师《重构》课程的培训，对重构及单元测试也有一定掌握，对重构了解较多，但对单元测试整个的理解还有所欠缺，所以参与了此次培训，当然也是收获颇丰。

参加本期培训本人主要有以下几方面体会和收获：

1. 写单元测试难

如果发现自己的代码没办法写单元测试，那就要怀疑是否是代码的架构问题。

如果单元测试不容易写，很大程度是因为源代码写的太烂。

2. 覆盖率问题

如果有了高覆盖率的测试代码，我们在重构，扩展的时候会方便很多，因此单元测试的代码不仅是为我们找Bug，更多的用途在于后期的维护和重构。

覆盖率能达到 80%，就非常不错了。不要盲目追求coverage达到100%，有些测试时无用的，比如简单的get set方法，或者Util类（都是static方法）的构造方法

3. 测试方法及工具使用

Mock与Stub的区别。桩对象：是桩对象时，断言是针对被测试类执行的。借助于桩对象，能够确保测试顺利运行。Mock对象：被测试类与模拟对象通信，模拟对象记录所有的消息。测试使用模拟对象来验证测试是否通过。

4. 良好的单元测试标准

1. 一个单元测试3A 准备，执行，断言；
2. 一个测试方法只能有一个 Mock；
3. 单元测试要遵循最小耦合法则，使它轻量级并且快速隔离。测试目的和职责明确。一个好的单元测试一定是可读、可维护、可依赖的；
4. 测试代码应尽量简单，每个测试只针对一个测试场景，并且不相互依赖；
5. 单元测试的方法名应该能描述所测试的场景和预期结果；
6. 单元测试方法之间不应该存在依赖；
7. 单元测试交互方法/无返回值，可以借助其他公有方法检查结果。

5. 编写高质量代码建议

1. 提升 sonar 标准，减少人工代码走查时间；
2. 建议 if、else、where 语句中只有一行代码；
3. 方法不要嵌套太多方法。