lsekfe 发表于 2021-6-22 09:15:50

在进行单元测试的时候,如何避免无用测试?

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

页: [1]
查看完整版本: 在进行单元测试的时候,如何避免无用测试?