一些單元測試的Guideline 單元測試工具
Jimmy Bogard 曾經寫過一篇文章： 《從單元測試中獲益》，這這篇文章中給出了下面三條規則：
“測試名應該從用戶的角度描述是什么和為什么” – 這樣一來，程序員可以從名字就可以知道用戶需要什么樣的軟件行為。
“測試也是代碼，同樣也需要我們更多的愛” – 真實運行在生產環境下的代碼不僅僅只是我們需要去關心和花心思的代碼。對于單元測試中的代碼同樣也需要易讀易維護，以及可重用的特性�！拔曳浅Ｍ春弈切┯珠L又復雜的測試代碼，如果一個測試需要30行的單元測試代碼，請把其放在一個方法中。一個長的測試步驟只會激怒程序員。如果你在正式的代碼中都沒有這么長的代碼，那么為什么我們需要在測試代碼中容忍這樣的情形呢?”
“不要只用一種固定的模式或組織風格” – 有些時候，對于一些特殊的測試案例，標準的類設計模式，或一個固有的測試裝置可能并不能有效的工作。
Lior Friedman 加上： “第0條 – 測試應該只測試單元其外部的行為，而不是內部的結構”�；蛘哒f，只測試對一個單元的期望，而不是這個單元的構成。
Ravichandran Jv 也加上了他的條例：
一個測試一個斷言(如果可能)。
如果在測試中有“if else” 的語句，請把if和else兩個分支拆分成兩個測試案例。
如果一個測試案例中也有if else 分枝，那么這個測試案例也需要被重構。
測試案例的命名代表了這種測試的類型。例如：TestMakeReservation() 和TestMakeNoReservation()是不一樣的類型。
Charlie Poole，NUnit的作者，重述了“一個測試一個斷言”成“一個邏輯斷言Logical Assert” – 他說， “有時候，因為我們測試API的表現不足，你需要寫多個物理的Assert才能達到一個完整的結果。許多使用NUnit框架API進行單元測試的開發，很不可能只使用一個Assert就完成了一個測試”。
Bryan Cook 也提供了一個不錯的可供考慮的列表：
做到：對Fixture一致地命名
做到：使用namespace
做到：測試方法的命名和Setup/TearDown 一致
考慮：分離你的測試和開發代碼
做到：測試的命令和被測試的功能一致
考慮：使用”Cannot” 前綴命名期望的異常
Bryan 有超過 一打的建議。
最后，有些人建議大家讀一下 Gerard Meszaros的書： “xUnit Test Patterns: Refactoring Test Code”
文章來源于領測軟件測試網 http://www.kjueaiud.com/
