不寫單元測試的廚師不是好司機

好吧，我認可題目就是個噱頭，無聊的時候自娛自樂是一種病，得治！

今天要說的話題就是單元測試。從題目提及，廚師和司機都是很是常見的職業，在他們的職業生涯中有着各自的單元測試（其實單元測試無處不在，這裏只是舉一個簡單的例子而已，請你們領會精神）。

菜桌上的每一道菜所經歷的每一個步驟都有單元測試。從種菜開始菜的種子要通過精心挑選的必須成活率符合標準纔會發放到各地的種子站。而後農民伯伯辛苦種菜拉到菜市場，到了菜市場想賣出去必須得有營業執照（不怕城管的好漢們除外）還得有衛生許可等等吧，每一步都是一個單元測試。相比而言那種自產自銷的農家做業要麼規模小要麼質量達不到保證。

和司機有關的事物更是如此，每輛在馬路上行駛的汽車它們的每一個螺絲釘都須要通過檢驗，最後車會被合格的部件組合到一塊兒。司機的駕照也是一個「單元測試」，社會是複雜的不能讓不安全的因素影響了其餘人因此保證（或者說盡全力保證）每一個人的質量是保證整個社會交通安全的重要手段。

不僅僅這兩個職業其餘的一切一切都是這個道理，要想保證一個複雜的工程成功那麼最有效的辦法就是將這個工程分工，而後保證每一步每一部分都是成功的，如此一來這個複雜的事情就有可能會成功，這裏僅僅是有可能而已，按照測試原理的說法就是，單元測試成功並不表明迴歸以及集成測試會成功。

因此這麼說來單元測試是成功不可或缺的一步，是保證成功的重要一個環節。

幾點要求：

• 每一個類都是應該能夠被測試的，並且是容易被測試的。這就要求編碼的時候要考慮單元測試，而不是單純爲了實現功能而實現功能。

• 單元測試覆蓋率是應該保證的，邊緣測試特殊值測試、以及條件分支的測試、異常捕獲後處理的測試等等這些是保證覆蓋率須要特別注意的地方。

• 若是用到了容器的東西，最著名的是EJB當中用到了服務器當中的東西，那麼該如何測試呢，如今方法有兩種，第一種是儘可能擺脫容器寫可測試的類。第二種是創建模擬的容器，將容器中的東西模擬進去而且賦值，最終判斷是否爲預期輸出。

單元測試每每進行是不順利的，由於不少coder不會寫單元測試更不會去考慮寫單元測試的人的感覺，因此不少void返回值的方法、不少借用容器變量的方法遍及類中，致使測試困難。在測試這些方法的時候須要變通一下，好比最簡單的就是測試list的add方法，返回值是void怎麼辦，能夠放進去而後拿出來看看是否放了進去，也能夠放進去以前看一下list的大小，而後放進去從新看一下大小。總之測試的意思就是代碼有沒有正常工做，不管是直接證實仍是間接的證實，只要你的理由充分的（或者必要的）那麼這個測試就能夠勉強說成是成功的。

目前爲止單元測試沒有提高到一個高度，由於從網上找一個單元測試的教程都找不到，找幾本單元測試書都很困難。開發過程當中開發團隊要麼沒有單元測試，要麼就是僅僅是一個擺設，這就說明不多有人去關心單元測試，也說明單元測試仍是頗有難度的。後面幾篇博客將詳細介紹筆者在開發過程當中如何作單元測試的，但願對讀者有用。