單元測試應該全面覆蓋專案開發的**，但是依賴的第三方**不應該被測試。
凡是非本專案開發的**，都可以認為是第三方**。
比如，我們專案依賴別的部門提供的儲存服務，連線此服務需要使用他們提供的乙個指令碼，而這個指令碼存放在我們的util目錄中。像這個指令碼，就是所謂的第三方**。
我用下面這段話來說服領導將這個指令碼從測試中移除。
我們的開發是建立在完全信任它的基礎上的。既然完全信任它，我們又何必針對它建立單元測試呢?即使它真的有問題，那也應該是提供它的團隊應該負責的事情。只應該測試本專案生產的**。如果我們測試a，就應該模擬b和c，而不是讓a直接呼叫b和c。
這樣能保證測試失敗的時候，準確的找到錯誤的原因。反之，可能是b和c的問題，但是a的測試失敗了，就會誤導測試人員。
有些專案中，測試**是先於開發**完成的。當我們想測試a的時候，可能b和c還沒有實現，這個時候，也是需要模擬b和c。
保證一次只測試乙個單元，能夠最大限度內聚測試邏輯，反映待測試單元的特性。
單元測試應該測試函式輸出是否符合預期。預期應該包含兩方面。當輸入在正常範圍時，返回的正常預期；當輸入在非正常範圍時，返回的錯誤預期。
舉個例子：
有個函式，叫 『煎雞蛋』。這個函式有如下功能：
* 當接收乙個雞蛋，就返回乙個煎蛋；
* 當接收乙個石頭，就返回乙個錯誤，內容是，『俺不會做石頭』；
* 當什麼都不輸入時，就返回錯誤，內容是，『對不起，巧婦難為無公尺之炊』。
我們測試的時候，就依據這三個功能點，進行測試。
煎雞蛋(雞蛋).should.equal(煎蛋);
煎雞蛋(石頭).should.equal(俺不會做石頭);
煎雞蛋(雞蛋).should.equal(對不起，巧婦難為無公尺之炊);
測試一定要覆蓋函式的所有功能點。
其實上面的例子已經接近測試驅動開發的概念了： 先設計煎雞蛋函式，想好它的功能點，然後宣告函式，對功能點一一編寫測試指令碼。在編寫指令碼的過程中，可能還會想到其他的功能點，比如，如果一次放入多個雞蛋，怎麼處理。這樣我們逐漸完善測試指令碼的過程中，功能逐漸的豐富起來。然後，依據測試指令碼，編寫煎雞蛋的實現。最後，測試，發布。
單元測試應該測試什麼？ Right BICEP
單元測試應該測試什麼？right bicep right 結果是否正確？b 是否所有的邊界條件都是正確的?i 能查一下反響關聯嗎？c 能用其它手段交叉檢查一下嗎?e 你是否可以強制錯誤條件發生？p 是否滿足效能要求？結果是否正確 這 個最簡單不過了，就是看程式執行之後的結構和文件是否一致。當然可能很...
單元測試應該測試什麼？ Right BICEP
單元測試應該測試什麼？right bicep right 結果是否正確？b 是否所有的邊界條件都是正確的 i 能查一下反響關聯嗎？c 能用其它手段交叉檢查一下嗎 e 你是否可以強制錯誤條件發生？p 是否滿足效能要求？結果是否正確 這個最簡單不過了，就是看程式執行之後的結構和文件是否一致。當然可能很多...
單元測試我們應該注意什麼！
今天老師在軟體工程中講了單元 測試這一環節，首先給我們乙個小函式，要我們分析它怎麼樣，如下 int largest int list,int length return max 針對這個函式我覺得有幾點可以說的。1.輸入陣列數值範圍影響程式正常執行。如輸入 1，2，3 1,2,3 0 1 2 257...