在Junit/Nunit测试出现之后，出现了一个工具Jcover/Ncover,此工具代码覆盖率分析工具，可以分析测试代码的测试范围的覆盖率。
第一次知道此工具的时候，相当的兴奋，因为这样可以轻松的把握项目中的测试代码情况。在看到自己的每行代码都被测试之后，相当的幸福啊，再加上Maven等工具可以自动连跑，那是足够保证了单元测试的覆盖率了啊。
正是因为不假思索的信任，导致了问题的出现：Cover工具的覆盖，是代码行的覆盖，而不是代码Step的覆盖。所谓的代码行，是指代码中可以被执行到的具体某物理行，但是Step则是指每一步逻辑。对于if (a==b||c==d||e==f)这样的判断，应该是有三个step在其中的。正是由于信任了Cover工具，导致代码覆盖率不够，未能测试到e==f的判断，导致了一个bug在最后才被发现。问题发现的越迟，付出的代价越大。
上面已经说明了全路径覆盖的含义（目前Cover工具无法达到的功能），那么全路径覆盖是不是很有必要且一定要的呢？答案是“YES”.做到全路径覆盖的测试是很痛苦的一件事情，但是，当你从全路径覆盖中找到重大问题时，才会回头来看“如果我做了全副该测试，这段路径的错误逻辑就不会出现的”。
就拿上篇"CheckedException VS UncheckedException"中的例子，当代码结构逐渐演化为多出入口调用C模块时，“C处不能决定具体的出错信息”。但是在代码中，如果恰恰就是在"C处误认为可以决定错误消息"时，对于这个“误操作”，就可以通过全路径覆盖发现这个问题。if(a==b||c==d||e==f) {throw new MyException("error msg.")}，这样的一行代码，需要面对三种问题去报出错信息，其负担太重，情况复杂（然后有了错误代码）。
如果做了全路径覆盖，可以走到（e==f）的判断，此时即可发现错误消息不正确的问题。
如何才能保证完成全路径覆盖呢？
1）手工debug跟踪，保证每一步都走到，对于最后的(e==f)，跟踪的好辛苦阿，创造这样的条件（走到e==f）就好累的。
2）利用Ncover的功能，对于这样的复杂逻辑，手工进行debug跟踪。
3)拆开代码，为三行（每个step为单独的一行），利用NCover自动分析。 哈，老师教过的"，不允许出现过于复杂的代码"这个原则被发挥到极致了。