在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自動分析。 哈，老師教過的"，不允許出現過于復雜的代碼"這個原則被發揮到極致了。