Thinking in unit test

一 置單元測試類與功能代碼類於同一包中

     如此，單元測試可獲得包訪問權限。

二 方法的設計
單元測試從根本上來講是為業務邏輯方法服務的，那方法做的好才是根本。舍本逐末而功成，吾未之聞也。
如果一個方法的行數是實際意義上的“屈指可數”

<甲>這個方法的單元測試更好設計一些
<乙>這個方法出錯的概率會小一些

我想這兩條理由已經足夠。。。

三 不要傷害自己的自信
當一個單元測試的錯誤沒有解決，不要寫第二個

四 單元測試不是二等公民
單元測試一樣需要我們的思考與設計，原因很簡單：需求在改變。我們需要我們單元測試是符合開閉原則的。

五 每一個測試方法只包含一個Assert語句。
當然不一定所有的測試方法都這麼幹，但要做到一個測試方法中含有最少的Assert語句。原因是：
<甲>可讀性強
<乙> 容易定位錯誤

六 保持每個單元測試的獨立性
設想：
如果某個單元測試失敗了，所有依賴它的單元測試也全部失敗了，我們如何確認錯誤的根源在哪裏？

七 構造-操作-檢驗（BUILD-OPERATE-CHECK）模式
單元測試不是二等公民，它當然需要可讀性，故每個單元測試最好按照構造-操作-檢驗模式分為三部分，第一部分構造測試數據，第二部分操作測試數據，第三部分檢驗操作是否與期望的數據一致。

若有其他見解，歡迎跟帖。