代碼的行為與我的期望一致嗎？
最根本的是，我們需要回答一個問題：“這段代碼達到我的目的了嗎？”先別太關心需求，當前要做的事情是確保一段代碼的行為與期望一致。
代碼的行為一直和我的期望一致嗎？
工程師在設計橋梁的時候，必須考慮負載、強風、地震、洪水等等，不能在因洪水出現問題后說，“如果風和日麗就不會有問題了”。
程序開發亦是如此。記得以前開發的時候，一個模塊開發完畢后，我就把那些相關的頁面打開，按正常的順序輸入正確的數據把功能走一遍，如果都通過了就交給測試人員。而測試人員最喜歡的一件事就是找出開發人員的bug，他們會想法按錯誤的順序輸入錯誤的數據，然后等著bug出現。
結果是，我的程序出了一堆bug，它們大多數都是因為錯誤的順序或者錯誤的數據，我氣憤地跟他們說，“你如果按正常的順序輸入正確的數據就不會有問題了！”
但事實是，測試橋梁時，不能僅選擇在風和日麗的一天，僅讓一輛車順利通過，這遠遠不夠。同樣的，在測試代碼的行為是否與期望一致時，需要確認：在任何情況下，這段代碼是否都與期望一致：比如文件不存在、權限不足、索引越界、網絡斷掉的時候。
我可以依賴單元測試嗎？
不能依賴的代碼是沒有多大用處的。更為糟糕的是，那些我們認為值得信賴的代碼（但其實是有bug的）有時候會讓我們花費更多的時間去跟蹤和調試。
沒有人能夠寫出完美無缺的代碼，但是這沒問題——只要我們知道問題的所在就可以了。
我們希望能夠依賴于所編寫的代碼，并且清楚地知道這些代碼的功能和約束。
單元測試能否表達我的意圖？
編寫單元測試，一個額外的好處就是它能夠幫助我們表達代碼的意圖。在效果上，它就像是可執行的文檔，說明了在用各種條件調用代碼時，我們對代碼行為的期望。
當團隊的其他成員看到測試代碼后可以將其作為代碼用法的示例。如果他發現了一個遺漏的測試用例，他會很快知道：代碼可能不支持這個用例。
1.4 如何進行單元測試？
單元測試是較為簡單易學的技術，如果遵循一些指導性原則，學習會變得更為容易和有效。
首先要考慮的是在編寫測試方法之前，如何測試那些可疑的方法。有了大概一個想法之后，可以在編寫實現代碼的時候，或者在此之前，編寫測試代碼。
下一步，要運行測試本身，或者所在模塊的其他測試，甚至是整個系統的測試，前提是它們要運行得相當快。重要的是所有測試用例都要通過，而不是僅僅新加的那個。這種基本的回歸測試（Regression Test）可幫助我們避免對其他的測試帶來間接的破壞。
我們還要借助于單元測試框架來進行測試，這樣可以大大提高效率。相關的知識可在后面的文章中介紹。
1.5 可是我還是不想測試
看了上面的這些介紹后，也許你能理解單元測試的必要性，也許你還在猶豫，而且還有不少的理由。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
