C#單元測試的一個小故事
C#單元測試小故事，或許你不了解或是正在學(xué)習(xí)C#單元測試，那么這個小故事的內(nèi)涵正式揭示了C#單元測試的實際意義，那么C#單元測試的意義是什么呢？它能帶給我們什么呢？讓我們來看看：
有一次，有兩個開發(fā)者：Pat 和Dale。他們面臨著相同的***期限，而這一天也越來越近了。Pat 每天都在著急地編寫代碼，寫完一個類又寫一個類，寫完一個函數(shù)又接著寫另一個函數(shù)，還經(jīng)常不得不停下來做一些調(diào)整，使得代碼能夠通過編譯。
Pat 一直保持著這種工作方式，直到***期限的前一天。而這時已經(jīng)是演示所有代碼的時候了。Pat 運行了最上層的程序，但是一點輸出也沒有，什么都沒有。這時只好用調(diào)試器來單步跟蹤了?！癏mm，決不可能是這樣的”，Pat 想，“此時這個變量絕對不是0 啊”。于是，Pat 只能回過頭來看代碼，嘗試著跟蹤一下這個難以琢磨的程序的調(diào)用流程。
時間已經(jīng)越來越晚了，Pat 找到并且糾正了這個bug；但在這個過程中，Pat 又找到了其他好幾個bug；如此幾次過后，bug 還是存在。而程序輸出那邊，仍然沒有結(jié)果。這時，Pat 已經(jīng)筋疲力盡了，完全搞不清楚為什么會這樣，認(rèn)為這種（沒有輸出的）行為是毫無道理的。
而于此同時，Dale 并沒像Pat 那么快地寫代碼。Dale 在寫一個函數(shù)的時候，會附帶寫一個簡短的測試程序來測試這個函數(shù)（C#單元測試的使用）。這里沒有什么特殊的地方，只是添加了一個簡單的測試，來判斷函數(shù)的功能是否和程序員期望的一致。顯然，考慮如何寫，然后把測試寫出來，是需要占用一定時間的；但是Dale 在未對剛寫的函數(shù)做出確認(rèn)之前，是不會接著寫新代碼的。也就是說，只有等到已知函數(shù)都得到確認(rèn)之后，Dale 才會繼續(xù)編寫下一個函數(shù)，然后調(diào)用前面的函數(shù)等等。
在整個過程中，Dale 幾乎不使用調(diào)試器（C#單元測試的功勞）；而且對Pat 的模樣也有些困惑不解：只見他頭埋在兩手之間，嘀咕著各種難聽的話語，咒罵著計算機(jī)，充血的眼球同時盯著好幾個調(diào)試窗口。
***期限終于到了，Pat 未能完成任務(wù)。而Dale 的代碼被集成到整個系統(tǒng)中，并且能夠很好地運行。之后，在Dale 的模塊中，出現(xiàn)了一個小問題；但是Dale 很快就發(fā)現(xiàn)了問題所在，在幾分鐘之內(nèi)就解決了問題。
現(xiàn)在，是該總結(jié)一下上面這個小故事的時候了：Dale 和Pat 的年紀(jì)相當(dāng)，編碼能力相當(dāng)，智力也差不多。唯一的區(qū)別就是Dale 非常相信單元測試；對于每個新寫的函數(shù)，在其他代碼使用這個函數(shù)并對它形成依賴之前，都要先做單元測試。
而Pat 則沒有這么做，他總是“知道”代碼的行為應(yīng)該和所期望的完全一樣，并且等到所有代碼都差不多寫完的時候，才想起來運行一下代碼。然而到了這個時候，要想定位bug，或者，甚至是確定哪些代碼的行為是正確的，哪些代碼的行為是錯誤的，都為時已晚了。
C#單元測試的小故事就向你介紹到這里，那么通過這兩個程序員的開發(fā)過程，大致的關(guān)于C#單元測試的理解是不是對你有點幫助呢？
【編輯推薦】
