Jester的独特之处

Jester是一款用来检查测试覆盖性的工具，它与其它类似工具的不同之处在于：其它测试工具的检测指标是每行被测代码是否被执行，而Jester则是通过一种奇怪的模式：改变一下被测代码的逻辑，执行一下测试用例，如果仍能全部通过，则表示测试有遗漏。

这种逻辑很古怪，但仔细想想就会发现它的合理之处，本文就不提了。

但是这种逻辑比起传统逻辑，即检测每行被测代码是否被执行的逻辑，到底强在哪里呢？一般来说，如果每行代码都被执行到了，那测试自然就完备了。

我被这个问题几乎搞得睡不着觉。由于智商太低，数理逻辑也不扎实，怎么想也想不出来。就当我要放弃的时候，灵感终于来了，我终于明白:
传统工具虽然可以找到未被测试的代码，但未必能找到未被测试的程序逻辑；为什么呢？因为有的逻辑是隐式的，而不是通过代码显式声明的。

举一个例子就能说明这个问题：

测试用例：

List resultList = ....;
testee.do(3,resultList);
assertTrue(resultList.size() == 1)

被测代码：

//Testee
public void do(int index,Collection resultList){
   if(index >= 3){
      resultList.add(new Object());
   }
}

被测代码只有一个If/Then逻辑。如果用传统检测工具来检查，那覆盖率肯定是100%，一切都很好。

但用jester来检查，jester就会报错。因为把  if(index >= 3) 变成  if(true || (index >= 3))后，测试用例仍然可以绿色通过。

这是为什么？ 因为jester期望测试用例能够考虑到 index < 3的情况。只有考虑到了index < 3的情况，在 if(index >= 3) 变成  if(true || (index >= 3))后，再执行测试用例，就应该可以遇到红色失败。(看官请闭着眼睛在脑子里想像一下个中缘由)

推尔广之，jester通过更改代码之种方式，可以挖掘出一个未明确写出来的逻辑：

//Testee
...
else{
  //do nothing
}

然后再检测这个逻辑是否被覆盖到。而传统的检测工具就做不到这一点!