- 1 只写必要的测试
编写自己觉得"没谱"的代码:比如说业务逻辑很复杂自己没完全吃透;或者以前没写过所以不知道是不是能行,也无法确定过程中是否会产生难以预料的变数等等.
- 2 只写关键的测试
有时候必要的测试你写不出来,又没有人指导,只能勉强可以跳过.但是关键性测试不要省.所谓关键性的测试:就是你所写代码里的核心逻辑;再换句话说就是如果一切顺利,它至少能够做到(或者不要去做)的那件事.这就意味着你可能忽略了一些边界条件的处理, 而且你也不知道该怎么处理,但是你至少保证了最重要的那条路线是可以走通的.将来重构的时候,这条关键路线能确保你不至于茫然无措.
如果在构造关键性测试用例的时候你发现你很难触碰到那一点(比如说前置条件你不会在测试用例里处理),那么很大的可能是你的这个单元过于复杂了,这是一个极好的立时重构信号.你可以尝试把要触碰的那一点逻辑抽取出来单独测试. 这样一来你至少做到了把核心逻辑分离出来,其他的代码就算再糟糕重构起来也会轻松得多.
- 3 无用的测试
- 3.1 不要去测试语言的核心库和／或标准库函数
如果你的代码简单到就调用了一句标准库函数, 那还浪费什么时间去编写测试啊.这些代码都是久经考验的. 虽然也有语言本身错误的小概率事件发生, 但由于标准函数的处理过程你触碰不到(常常深埋于虚拟机中或调用系统底层接口)所以你的测试对你自己的代码丝毫没有帮助.(当然,如果您是专家级程序员则不在此例,说不准您就是等着解决这个问题呢)
- 不要去测试框架的基础类或工具方法
道理和第一条类似,知名的框架都有很完善的自身测试,否则你也不敢用不是? 如果你确信是框架自身出了问题,你的测试更应该去应用在框架本身上,说不定你可以做出个补丁为该项目做出贡献.
顺手举个例子: 你继承了某框架的(Model)层, 然后在里面定义了检查其实例的某一属性是否为空的验证(使用框架自带的验证方法,而不是自己编写的).这种情况就没有必要测试这个检查是否生效,除非你这个类在初始化的时候返回的是其他类的实例……你项目组里有这么无聊的人吗?
- 3.3 不要去测试外部依赖的有效性
这是初学者常常陷的坑,而且往往把自己折磨到不行. 这里有两个问题: 第一, 如果你的测试一定需要外部依赖, 你首先应该考虑伪造它, 而不是在 A 的测试里先检查 B(也就是说, 你的测试目标是 A, 为了完成这个测试用例, 你需要用到 B 并且 B 的某种特性一定要成立, 这是先决条件, 于是你不得不写一句断言先测试这件事情, 然后才能测试真正的目标 A).如果你能伪造一个 B, 叫 B', 那么 B' 不一定非要和 B 完全一样, 只要它能表现出来恰好满足本次测试用例的特征就足够了.这样事情就会变得单纯的多. 其次, 即使你无法伪造 B(基本上是因为不会), 那么你至少应该把对 B 的特性测试转移到 B 自己的单元测试中去.
- 3.4 最后还有一种测试是"无用"的
就是从来只见它(通过)没见过它(失败)的测试.你自己都没意识到这种测试可能从头到尾都没有测试任何代码! 这也是 TDD 强调先红后绿再重构的原因之一, 你至少应该在最开始让测试用例失败一次, 否则等测试数量变多以后再去分辨就来不及了.另外重构完了也最好手动破坏一下代码(比如随便往里面打几个无意义的字符)诱使测试报错, 以确保测试真的覆盖到了目标代码.