好吧，我承認題目就是個噱頭，無聊的時候自娛自樂是一種病，得治！
今天要說的話題就是單元測試。從題目說起，廚師和司機都是非常常見的職業，在他們的職業生涯中有著各自的單元測試（其實單元測試無處不在，這裡只是舉乙個簡單的例子而已，請大家領會精神）。
菜桌上的每一道菜所經歷的每個步驟都有單元測試。從種菜開始菜的種子要經過精心挑選的必須成活率符合標準才會發放到各地的種子站。然後農民伯伯辛苦種菜拉到菜市場，到了菜市場想賣出去必須得有營業執照（不怕城管的好漢們除外）還得有衛生許可等等吧，每一步都是乙個單元測試。相比而言那種自產自銷的農家作業要麼規模小要麼質量達不到保證。
和司機有關的事物更是如此，每輛在馬路上行駛的汽車它們的每個螺絲釘都需要經過檢驗，最後車會被合格的部件組合到一起。司機的駕照也是乙個「單元測試」，社會是複雜的不能讓不安全的因素影響了其他人所以保證（或者說盡全力保證）每個人的質量是保證整個社會交通安全的重要手段。
不單單這兩個職業其他的一切一切都是這個道理，要想保證乙個複雜的工程成功那麼最有效的辦法就是將這個工程分工，然後保證每一步每一部分都是成功的，如此一來這個複雜的事情就有可能會成功，這裡僅僅是有可能而已，按照測試原理的說法就是，單元測試成功並不代表回歸以及整合測試會成功。
所以這麼說來單元測試是成功不可或缺的一步，是保證成功的重要乙個環節。
幾點要求：
單元測試往往進行是不順利的，因為很多
coder
不會寫單元測試更不會去考慮寫單元測試的人的感受，所以很多
void
返回值的方法、很多借用容器變數的方法遍布類中，導致測試困難。在測試這些方法的時候需要變通一下，比如最簡單的就是測試
list
的add
方法，返回值是
void
怎麼辦，可以放進去然後拿出來看看是否放了進去，也可以放進去之前看一下
list
的大小，然後放進去重新看一下大小。總之測試的意思就是**有沒有正常工作，無論是直接證明還是間接的證明，只要你的理由充分的（或者必要的）那麼這個測試就可以勉強說成是成功的。
目前為止單元測試沒有提公升到乙個高度，因為從網上找乙個單元測試的教程都找不到，找幾本單元測試書都很困難。開發過程中開發團隊要麼沒有單元測試，要麼就是僅僅是乙個擺設，這就說明很少有人去關心單元測試，也說明單元測試還是很有難度的。後面幾篇部落格將詳細介紹筆者在開發過程中如何做單元測試的，希望對讀者有用。
寫單元測試的知識結構 1 單元測試用處
1讓機器去做重複的事，而不是每次都由程式設計師配置引數 開啟ide專案 編譯 執行 使用程式 跟蹤斷點 檢視變數，如果想檢視 底層 改動對用例帶來的影響，執行單元測試就看見了，當然增加的邏輯單元和需求單元得額外得寫新的單元測試。2 作為程式改進設計的依據，如果你現在的對一段 的想法是沒法去測試，基本...
三問TDD 單元測試總是好的嗎？
原帖 再問tdd 擴散角模型 有關測試 後行 也可以接受的說法，說明了乙個事實 即使是最中堅的測試粉絲，也經常需要修正自我。很多理論丟擲來之後，在現實面前，都不斷的妥協。一些妥協到基本完善，一些妥協到基本完蛋。說實話，我表面上是乙個保守派，其實骨子裡是個激進派。幾年前我的想法深度和廣度都不足，實際上...
倒底該怎麼寫DAO的單元測試？
code public void testadduserinfo throws exception code 為了避免髒資料！所以要把新插入的資料用removeuser刪除掉！當然，如果使用spring的那個帶有事務的基類。在teardown時，會回滾所有事務。removeuser這個方法可以無需要...