【游戏编程扯淡精粹】单元测试
我的使用体验
单元测试是公司不太重视的，我尝试了一下，先从自己负责的代码模块开始做
经过一个月的努力后，我放弃了，并且又过了一段时间，把代码恢复成原样
这次实验不利的原因有：
- 策划需求不稳定，然后对应的代码功能，用例都需要推翻，维护成本很高，需求都应付不过来，哪还能测试呢？
- 依赖注入需要对代码进行较大改动，使得代码复杂化，我觉得别人不知道我在做依赖注入，他是不能理解我为什么这么写的
- 依赖注入的难点，是引擎框架，entity和property（属性同步），这个太繁琐了
业务需求不稳定，是阻碍单元测试的根本原因
依赖注入（DP/DI）
- 基本思想：将延时，随机数等影响测试的内容抽取出来，使用mock替代
- 我的使用体验：使得代码复杂化，需要权衡测试的价值，最终在项目开发中放弃
time.sleep要耗时
通过构造函数的依赖注入解耦，真实运行时选择time库注入，测试时注入mock
被测试的scheduler类
测试scheduler的单元测试类
Mock
Mock的作用是前后端分离开发，前端需要mock后端的接口数据，避免阻塞前端开发和测试
覆盖率
覆盖率很像缓存，缓存的miss rate才是重要的，覆盖率没覆盖到的地方才是重要的
没有覆盖的往往是一些细小的分支，却是BUG的温床
我的使用体验：单元测试量不够，要做到全覆盖需要很多时间编写用例