Object Mother Pattern 優缺點

最近有人提到 Object Mother ，嗯，寫一下近來的發現吧

先講講缺點：

• Object Mother (OM) 的理念是可以註冊要清理掉的物件，以便在 tear down 的時候可以全部 purge。其實這個理念並不好 implement，目前也沒看過有什麼 framework 可以幫的上忙的。我自己的話多是用在 database相關的物件生成，一方面是 DB 的資料準備很複雜，另一方面是 Hibernate 的 session.delete(object) 在 purge 的時候幫了大忙。即使如此，註冊 object 還是要手動進行。手續很繁瑣...



• OM 和 test code 本身 "距離太遠" ，造成 test code 閱讀困難。距離就是 test code 和 OM 之間相隔的 method和class 數。當 developer 看到 test code 時，他還要額外的去翻那個 OM 出來看，才知道到底產生的物件長什麼樣子，横跨兩至三個class，太遠了。如果 OM 又呼叫其他的 OM，那距離又更遠了，可讀性變更差...



• 距離遠帶來的不僅是程式易讀性的問題，還會造成 test 過慢。我曾經實做過 Fixture 最大有 call 到三層的 OM，而且每一層都會 hit database，喔~~ my God ! 才十個 test case 總共要 run 30 秒以上。



• 上面提到像是連call好幾層的 OM，其實已經超過 unit test 的範圍，等於是在做 integration test了。而且有個嚴重的問題，就是當 OM 層層呼叫時，有時最前面的錯誤會一直累積到最後面還不會發現... 因為後面的 test case 都是一直根據前面的建立的 "範圍" 下產生的。例如最前面的資料沒有cover負值的範圍，後面的 test case 如果一直按這個 OM 產生的資料寫測試。久而久之就會出現後面的 class 沒測到負值的範圍(或者是 side effect)。這個實務上我碰過一次，當時真的是嚇呆了。因為沒想到會在最前面藏著這麼一個 bug.

嘿，換來講講優點吧：

• 寫了這麼多 OM 發現到，其實清理物件也是 test 的項目之一啊！常常會發現如果無法正常的 tear down ，那大概是程式有哪裡忘了關 resource (例如 IO 忘了 close, 或兩個 object 同時 reference 到同一個 hibernate PO) 所以花時間寫 OM 的註冊和 purge 其實是值得的，因為 release resource 也是程式中重要的一環啊。



• OM 在 team 裡面很好用的，只要有一個人寫出來，大家都可以用，不用每個人都需要知道怎麼正確產生 object 的各種 state。



• 上面說到了，OM 就是迷你的 integration test，相信這付出的額外代價會有回報的。



• 極困難測試的變成可以測！測試寫的再慢再難懂也比沒有測試強上一大截，這是最重要的啊~ :-)

有機會再寫一些 Object Mother + Hibernate 的做法吧 (其實很單純.... 沒什麼了不起....)