如果單元測試的結果是錯的，那一定是程序出了問題，而且這個錯誤一定是可以重復的。
問：如果用隨機數以增加測試的真實性，好么？
答：一般情況下不好，如果某個隨機數導致程序出錯，但是下一次運行又不能重復這一錯誤，于事無補。要注意我們還是要用隨機數等辦法“增加測試的真實性”，但是不是在單元測試中。單元測試不能解決所有問題，所以也不必期望它會發現所有的缺陷。
1.4.2.6 獨立性，單元測試的運行/通過/失敗不依賴于別的測試，可以人為構造數據，以保持單元測試的獨立性。
程序中的各個模塊都是互相依賴的，否則它們就不會出現在一個程序中。一般情況下，單元測試中的模塊可以直接引用其它的模塊，并期待其它的模塊能返回正確的結果。
如果其它的模塊很不穩定，或者其他模塊運行比較費時（如進行網絡操作），而且對于本模塊的正確性并不起關鍵的作用。這時可以人為地構造數據以保證這個單元測試的獨立性。
New Object
New user
Get user permission // go thru the server to get the correct permission, you can also mock the permission object.
Object.Test(user)
1.4.2.7 單元測試應該覆蓋所有代碼路徑，包括錯誤處理路徑，為了保證單元測試的代碼覆蓋率，單元測試必須測試公開的和私有的函數/方法。
單元測試必須覆蓋所測單元的所有代碼路徑。
問：��！這樣豈不是要寫很多啰里啰唆的測試方法？
答：對，因為程序中很多缺陷都是從這些啰里啰唆的錯誤處理中產生的。如果你的模塊中某個錯誤處理路徑很難到達，那你也許要想想是否可以把這個錯誤處理拿掉。
[大栓：這對于那些愛寫復雜代碼的人是一個很好的懲罰，不對，是一個很好的鍛煉。]
[阿超：對，把單元測試的責任和代碼作者綁定在一起后，代碼作者就能更真切地體會到復雜代碼的副作用，因為驗證復雜代碼的正確性要困難得多。要注意的一點是：100%的代碼覆蓋率并不等同于100%的正確性，請看下列例子]
e.g. didn’t check return value.
e.g. memory leak
1.4.2.8 單元測試應該集成到自動測試的框架中
另一個重要的措施是要把單元測試自動化，這樣每個人都能很容易地運行，并且單元測試每天都可以運行。每個人都可以隨時在自己機器上運行。團隊一般是在每日構建中運行單元測試,這樣每個單元測試的錯誤就能及時發現并得到修改。
1.4.2.9 單元測試必須和產品代碼一起保存和維護
單元測試必須和代碼一起進行版本維護。如果不是這樣，過了一陣，代碼和單元測試就會出現不一致，而且所有代碼的作者要花時間來確認哪些是程序出現的錯誤，哪些是由于單元測試更新滯后造成的錯誤。。。這樣就失去了單元測試的意義，同時又給大家增加了負擔，折騰多次以后，大家就會覺得維護單元測試是一件很費時費力的事。
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/
延伸閱讀
