[ASP.NET]專案自動化測試
前言
TDD(Test-Driven Design)這個term大家都聽到耳朵長繭了，
但實際上有多少專案，甚至產品可以規劃分析到先寫Unit Test，我想大家心知肚明。
光SA階段要能訂出Test Cases就是一件難事了。
但，若整個系統生命週期，能有始有終的做好自動化測試，就能用有形的開發測試成本，來補足之後無形的維護風險成本。
測試其實是每個系統開發過程中，避免不了的動作，但要做到完整，卻是難上加難。
包括機制、工具survey與評估、規劃、 training成本、維護測試程式成本等等…每一項都在在挑戰著PM或MGR的極限。
測試要做成什麼樣的程度，其實真的可以彈性調整…難的部分還是在要有始有終，不然就是功虧一簣。
使用工具
由於專案是ASP.NET開發的，所以選擇的工具都是for .NET developer的，
- NUnit：Unit Testing(usually for BLL and DAL)
- NCover：測試程式覆蓋率
- NAnt：撰寫排程執行哪些自動測試
- CC.NET：Continuous Intergation tool，將上述排程執行auto build的結果，透過漂亮的平台呈現出來，提供測試報告與email通知等等…（雖然java的Hudson實在漂亮很多）
- WatiN：Web UI testing
- Sub Version：提供最新程式與版本號資訊
上述這些工具，當然都是不用錢的…也有不少東西，是從java那邊演變過來的。
實際應用範例
這邊要感謝公司內有一位資深同事Cigala所規劃的自動化測試環境，讓我可以瞭解整個自動化測試的藍圖。
也供大家參考看看…
結論
自動化測試，是一件大工程，但對大型專案、長期使用的產品，卻是最穩固的基礎…
沒有人可以承擔起改bug或設定後，系統其他功能crush的責任。
最基本的，還是要對核心功能模組進行撰寫Unit Test的程式，用20％的成本去做到80%的迴歸測試，
其他部分，可以等待成本、時間得以緩頰時，慢慢補充(尤其是造成bug的Test Case最有價值)。
單元測試，就像捷運一樣，
一次要把所有地區都蓋好捷運，時間成本根本就不允許。
單元測試就如同把整個系統切成很細的單元來測試，
就像只在某個區域蓋好捷運，當然當該區域的地質、路段有所變更時，捷運的建設也要跟著更改。
當每個區域的捷運都蓋好後，只需要進行連結的動作即可。
如果大家有看Refacotring那本書，(blog右欄那本)
系統進行深度較深的Refactoring時，最大前提就是要建好測試程式，
因為沒測試程式的話，沒人敢保證，Refactoring後不會影響到舊的功能。
另外，大家身為資訊人應該都體會過，維護前人系統的切身之痛，
單元測試報告，就是最好的交接證據證明…證明交到你手上時程式是可以正常運作的，
也可以考慮把單元測試報告當作外包或人員工作交接，必要提供的一份資料。
blog 與課程更新內容，請前往新站位置：http://tdd.best/
