在Junit/Nunit測試出現(xiàn)之后，出現(xiàn)了一個工具Jcover/Ncover,此工具代碼覆蓋率分析工具，可以分析測試代碼的測試范圍的覆蓋率。
第一次知道此工具的時候，相當(dāng)?shù)呐d奮，因?yàn)檫@樣可以輕松的把握項(xiàng)目中的測試代碼情況。在看到自己的每行代碼都被測試之后，相當(dāng)?shù)男腋０。偌由螹aven等工具可以自動連跑，那是足夠保證了單元測試的覆蓋率了啊。
正是因?yàn)椴患偎妓鞯男湃危瑢?dǎo)致了問題的出現(xiàn)：Cover工具的覆蓋，是代碼行的覆蓋，而不是代碼Step的覆蓋。所謂的代碼行，是指代碼中可以被執(zhí)行到的具體某物理行，但是Step則是指每一步邏輯。對于if (a==b||c==d||e==f)這樣的判斷，應(yīng)該是有三個step在其中的。正是由于信任了Cover工具，導(dǎo)致代碼覆蓋率不夠，未能測試到e==f的判斷，導(dǎo)致了一個bug在最后才被發(fā)現(xiàn)。問題發(fā)現(xiàn)的越遲，付出的代價越大。
上面已經(jīng)說明了全路徑覆蓋的含義（目前Cover工具無法達(dá)到的功能），那么全路徑覆蓋是不是很有必要且一定要的呢？答案是“YES”.做到全路徑覆蓋的測試是很痛苦的一件事情，但是，當(dāng)你從全路徑覆蓋中找到重大問題時，才會回頭來看“如果我做了全副該測試，這段路徑的錯誤邏輯就不會出現(xiàn)的”。
就拿上篇"CheckedException VS UncheckedException"中的例子，當(dāng)代碼結(jié)構(gòu)逐漸演化為多出入口調(diào)用C模塊時，“C處不能決定具體的出錯信息”。但是在代碼中，如果恰恰就是在"C處誤認(rèn)為可以決定錯誤消息"時，對于這個“誤操作”，就可以通過全路徑覆蓋發(fā)現(xiàn)這個問題。if(a==b||c==d||e==f) {throw new MyException("error msg.")}，這樣的一行代碼，需要面對三種問題去報出錯信息，其負(fù)擔(dān)太重，情況復(fù)雜（然后有了錯誤代碼）。
如果做了全路徑覆蓋，可以走到（e==f）的判斷，此時即可發(fā)現(xiàn)錯誤消息不正確的問題。
如何才能保證完成全路徑覆蓋呢？
1）手工debug跟蹤，保證每一步都走到，對于最后的(e==f)，跟蹤的好辛苦阿，創(chuàng)造這樣的條件（走到e==f）就好累的。
2）利用Ncover的功能，對于這樣的復(fù)雜邏輯，手工進(jìn)行debug跟蹤。
3)拆開代碼，為三行（每個step為單獨(dú)的一行），利用NCover自動分析。 哈，老師教過的"，不允許出現(xiàn)過于復(fù)雜的代碼"這個原則被發(fā)揮到極致了。