单元测试 - 开发建议 ¶
作者：KK
发表日期：2015.12.13
修改日期：2016.12.4
优化了内容描述
不能一直用
assertTrue¶断言取代所有断言，该用哪种就用哪种，必要时增加最后一个参数填写断言说明，那么你想用的判断该用哪个断言呢，就要在本教程的断言大全里面找了，或者百度，比如要断言大于小于的，在断方大全里
Ctrl+F搜索大于一般就能找到，常用的多搞几遍就熟悉了，就像平时用别的类的方法一样
测试用例要分门别类 ¶
测试方法会越来越多，你的测试用例代码会变胖，到时候记得将各种测试目的分门别类，分成多个测试用例，也要分一下目录，创建测试用例时可以声明目录的嘛
恢复测试产生的数据变化 ¶
你做着做会遇到这样的问题：测试get的东西还好，get个变量断言是不是预期值，但如果要测试添加或更新数据呢？这里会引发一个问题，假设你要测试一个活动模型，为这个模型不断add了一些模拟的积分用户，然后判断get第一名是否有预期的数据，好了预期到了，可是下次跑测试的时候，再add就不对了，因为第一名已经判断出来并存在数据库了，怎么办？那所以这种测试就要有模拟数据场景和销毁模拟数据的行为了
很简单，Codeception可以让你设置一个数据镜像，每次启动测试时都将数据库恢复到这个镜像的数据状态，所以重复运行测试是不会累积添加的数据的
但有些项目不方便做数据镜像，那就要靠自己写数据恢复代码了
测试用例生成的时候都有 _before和_after方法，在_before里将数据库里的东西该删就删，该添就添，模拟成你要测试的起始状态，然后测试完了就在_after里将刚才添加的数据删光，把该恢复的数据恢复回去就行了，模拟数据场景是一个麻烦事，但这个不可避免
标记哪些方法已经被测试 ¶
单元测试的主要责任就是测试一个类的各个方法是否工作正常，我们的项目会增加越来越多的类和方法，那也要一一增加测试方法，还有旧的类库也不是都有测试用例的，日后要慢慢一一补充的，于是我们需要识别哪些类的哪些方法是不是已经测试了，所以你需要想一个办法来管理各个类的方法是否已经被测试。
我的方法就是在被测试的方法中添加
@test的注释（相关文章）
判断哪些类和方法要编写单元测试 ¶
你可能会问是不是项目每增加一个类都要写单元测试呀？这个看项目情况的，如果观念非常严谨要求丝毫不能出错，那肯定要最大限度保证所有类都能有测试代码。但多数项目都不是非常严谨的，那就建议只针对核心类和被很多地方调用的类来写测试，临时的/少调用的/非核心的类就可以不必为它写测试方法，尽管它们其实也可能会在修改中出错，但影响面会小一点，你觉得能接受就行，一切其实都是看性价比，你觉得值了就写，不值了就别写，但如果你一丁点都不写我认为真的不好~
欠缺的断言方法 ¶
有时我们要断言一个值是不是数字，我之前并不提倡大家用
assertTrue去取代所有断言，就像你要断言一个值是字符串应该用assertInternalType('string', $str),因为单元测试模块自带了针对字符串类型的断言方法，可是却没有提供针对数字的断言，于是只能通过assertTrue(is_numerice($number))来实现了，变通点即可，规则死人是活你懂
要断言什么内容 ¶
测试开发的过程中，你会遇到“
到底要断言什么，断言多少东西？"的问题，比如一个模型的getXXX获取数据方法，完整地说要先断言返回值是不是数组
再断言数组里的key都有哪些
还得断言每个key的值是什么类型。..值的范围 ...
哇这不是要写很多很多断言代码？这样比程序业务代码还多的样子哦。
在这方面我也没有完整的答案给到你，因为我没专门研究过测试开发的理论和概念内容，个人总结的工作经验就是:看性价比，你觉得哪些容易出错，后期修改容易造成误差的内容嘛，就测那些好了。不然你测得再多，有的本身就很稳定，永远不出错，你这个测试代码可能就白写了，自己学会把握哦
可以看看我这个测试用例都在断言些什么：例子