如何寫unit test

以前覺得unit test不就寫test case
想到啥，就寫啥，沒有目標的亂寫
記得以前連搬檔案都寫了一個case來測
最近領悟了點東西，趕緊來整理一下

• 測試資料
  寫test case最麻煩的地方在準備測試資料
  由於資料大多存取DB，因此得準備一個測試DB
  但資料被改後，還得再倒回去，否則test case會fail
  以前都用dump，再整個倒回去
  開發上還挺累人的
  
  個人測試還好，多人用同一個測試DB，就會互相蓋DB
  難道要一人一DB嗎... 這提出申請，一定被上頭打槍...
  
  後來才瞭解，這不是unit test
  這已經是integration test(接DB)
  unit test應該在幾秒內跑完才叫unit test
  
• 利用Mock & Stub模擬測試資料
  後來就利用這做法，避免接DB，及外部API的動作
  說方便... 是比接DB方便... 但也還好...還是得寫一堆code，只為了準備測試資料
  想利用TDD寫好unit test，還是挺花時間的
  要說服其他人用，力道上還是不夠
• 測邏輯就好
  直到前陣子，Kent Beck, Martin Fowler及DHH在討論「 IS TDD DEAD 」
  DHH在說實務上用TDD不可行，當然是被兩位大師訓了一頓...
  不過影響最深刻的是Martin Fowler說他幾乎沒在寫Mock
  
  實在太令人驚訝了...居然沒在寫mock.....
  很想實際看一下些大師怎麼寫的...
  
  雖然還是不知道大師怎麼寫的
  不過自己重新領悟unit test就是在測試邏輯
  即然是測邏輯.... 那.... 就把邏輯這段再抽成一個function獨立出來就容易測了
  YA~~
  現有終於可以輕鬆的寫test case (泣)
  

當然~ 難免有些地方還是不好寫unit test
大師也說... 不好寫的就不要刻意寫，工具有他的極限
不要硬寫，而搞死自己 <= 好吧 這句是我自己將來為了辯解沒寫unit test的藉口