单元测试复盘和规范整理

对战服务器开发引入了单元测试环节，效果不错，后期重构代码，优化性能等都有了保障，甚至帮我查出了两个导致内存占用居高不下的隐藏问题。

编写单元测试需要有正向的认知和心态。
1. 首先需要正视单元测试的正向意义,单元测试可以驱动（如：TDD）和验证功能实现，也能能保护已有的功能不被破坏，对于追求稳定性的模块来说耗费时间编写单元测试是值得的。
2. 明确当前项目是否需要单元测试，然后按照规范认真编写，避免马马虎虎，写出无效的单元测试，浪费时间。
3. 编写单元测试并不是一件简单的事情，需要周密的思考，迷茫的时候，需要停下来思考导致迷茫某些单元测试无从起手的根源。
4. 编写单元测试是一件繁琐的事情，需要一定的耐性，按照业务需求编写尽量完善的测试。

并且编写单元测试并不容易，并且需要一定的技巧，可以参考以下业界规范：
(1). 测试准则(AIR原则)
A：Automatic（自动化）
单元测试应该是全自动执行的，并且非交互式的。测试用例通常是被定期执行的，执行过程必须完全自动化才有意义。
输出结果需要人工检查的测试不是一个好的单元测试。单元 测试中不准使用 System.out 来进行人肉验证，必须使用 assert 来验证。
I：Independent（独立性）
保持单元测试的独立性。为了保证单元测试稳定可靠且便于维护，单元测试用例之间决不能互相调用，也不能依赖执行的先后次序。
R：Repeatable（可重复）
单元测试是可以重复执行的，不能受到外界环境的影响。如果单测对外部环境（网络、服务、中间件等）有依赖，容易导致持续集成机制的不可用。

(2). 编码原则
必须符合 BCDE 原则：
B：Border，边界值测试，包括循环边界、特殊取值、特殊时间点、数据顺序等。
C：Correct，正确的输入，并得到预期的结果。
D：Design，与设计文档相结合，来编写单元测试。
E：Error，强制错误信息输入（如：非法数据、异常流程、非业务允许输入等），并得到预期的结果。
避免以下情况：
1）构造方法中做的事情过多。
2）存在过多的全局变量和静态方法。
3）存在过多的外部依赖。
4）存在过多的条件语句。
建议：
1.涉及到的某些扩展模块可以使用mock模拟
2.测试用例不要使用@ignored或者被注释掉，切记切记。

(3).测试目标
语句覆盖率：>=70% 分支覆盖率：100% 函数覆盖率：100% 行覆盖率： >=80%
执行覆盖率, 业界标准通常在 80% 左右!!