好的單元測試專注於要測試的一小塊**，也就是我們所說的「單元」，測試與越多**打交道，越容易偏離
不要依賴外部儲存，因其他人可能也正在使用，導致單元測試執行結果不可控
單元測試不要依賴於其他單元測試，即時是同乙個測試套，即時仔細調整了順序，還是有可能因為依賴鏈的問題失敗，因此測試間也要彼此隔離。
在任何時間以任何順序執行任何乙個測試都不會失敗
乙個單元測試應該關注與邏輯的乙個方面，如果要在某個單元測試中加入斷言，需要考慮乙個，這個斷言真的是我需要的嗎？如果確實描述了某個場景，那是否要將該斷言抽取為乙個測試方法呢？
測試用例的單一職責反過來會要求類/方法的單一職責（srp），這也同時反向驅動了類/方法的完善
自驗證的測試用例可以引入持續整合（ci）提供質量保障
如果編寫單元測試成為習慣，那很大可能會倒逼**編寫時考慮易測試性，從而間接提高**質量
編寫優秀的單元測試（五）編寫測試
準備 執行 斷言 arrange act assert 這個流程是 準備用於測試的物件 觸發執行 對輸出進行斷言 怎麼寫測試是個問題，寫多少測試，也一直是個問題。這裡我們給出乙個建議 檢查行為，而非實現。具體來說，我們應該跳出具體的實現，把關注點放在我們期望類有怎樣的行為上，不應該讓實現主導測試，而...
編寫優秀的單元測試（二）測試先行
測試先行就是我們常說的測試驅動開發 tdd 測試先行的實踐方式是在接到乙個新功能的時候，先寫乙個測試，這個測試一定會失敗，然後編寫 使得測試成功，然後再寫下乙個測試，有點像是填坑的方式進行開發。傳統的開發方式是 設計 開發 測試 如此往復 測試先行的開發方式是 測試 重構 如此往復 下圖指示了設計先...
編寫優秀的單元測試（六）編寫可讀的測試
網上有乙個段子，說程式設計師最煩做的兩件事情，乙個是寫文件，乙個是寫注釋。程式設計師最煩別人不做的兩件事情，乙個是不寫文件，乙個是不寫注釋。這裡提到了程式開發裡面的乙個最基本的事實 讀 比寫 難。這也是我們經常在工作中重構的原因，因為我們經常覺得有看那些 的時間，我都重寫一遍了。說這些是為了告訴我們...