隱藏在mock之后的‘快感’

      最近某同事抱怨他們的測試難寫，經常花費在測試的時間比產品代碼更多，而且每次重構后都必須修改一大堆的測試。和同事閑談后得知，在其項目中大量的使用了mock，或者說對mock的使用過度極端對所謂的單元測試“快速”，“獨立“的過度。 在前邊轉載過《軟件開發中沒有所謂正確的方法》，當你把某一種方法論作為銀彈使用的時候，早晚魔鬼會伴隨在你身邊。

    Mock給我帶來了感知，剝離了類與類之間的依賴，有助于我們更好的工作在當前的關注點 .但同時由于太多的對場景的假設，導致這塊代碼成為了信息的孤島，甚至很多時候不得不用mock的第二特性verify，order，以至于你的測試關心的不再是代碼存在的business邏輯，而傾向代碼層面的設計實現，這就把你單元測試推向了“白盒測試“的位置，導致測試變為脆弱的測試。每當簡單的重構導致內部的變化，你的測試也必須隨著改變。

    鄙人認為作為一個好的測試而言，在一次合法的簡單重構之下，是不需要修改測試的，因為你修改的只是內部實現，而不是business的改變，如果你邊改測試邊重構或者重構后掛到一大堆測試，這意味這你的測試不是一個穩定的測試或者你不是一次合法的重構（也許redesign，override）。

    在同事的項目中對mock的極端到了對簡單的View Object 也采用builder模式，可是內部卻全是mock given。在我看來而言View Object只是一個簡單的數據載體，不存在行為邏輯，我們毫無必要去做mock，mock該是針對假設，而應該盡量避免對狀態mock。在同事的項目中導致需要寫一個測試之前，作為測試的準備given ，必須理解存在代碼的實現，因為你需要一堆given，比如對于person對象，如果你在實現中需要得到account則：

given(person.getAccount()).willReturn(some account);

    導致我需要了解實現需要什么property，如果我需要新的的property也許只是簡單的把某個“依戀情結”放入了object，測試也需要被修改，導致重構者對自己的重構并不那么自信，這將影響重構成為日常行為，隨著堆積的”壞味道“這將一點一點的侵蝕你的代碼，項目慢慢的也許會不能的不可控。

    Mock并不是一個壞的東西，結果的好壞在于使用的人，團隊 的意識，如果是mock anywhere或者杜絕mock走向兩個任意的極端都將是一個錯誤的抉擇。

    Mock更多的使用場景為對外界資源解依賴增強感知能力，以及對無響應的重要business的驗證，后者長體現于一個沒有返回子void的method，但是method比如增加用戶積分，記錄用戶信息等的。然而對于有響應的business，我需要的不是mock而應該是assert，對于測試來說對于business來說應試是我的輸入應該得到我預期的響應，而非我verify某個行為發生了，那么其結果一定就正確，當然對于實現來說這是成立的，但是從測試的價值來說這廝無意義的，這將是一個脆弱的測試，我認為一個好的測試將是“黑盒測試“，是一個business的描述，對一份約定，契約的闡述。

     附言，如果你因為測試的速度，獨立性來為自己的mock證明，那將是無意義的，不是每一個測試都必須在黃金法則內（0.1s），如果你對外部依賴，耗時依賴的分離，這我相信將不再是問題所在，測試的優化將是另一個有趣的話題，將不是本問內容之列。