如何寫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的藉口

[書]敏捷與Scrum軟體開發速成

最近在聽同事在提Scrum
自己的team都是用XP開發
Scrum這詞也聽好幾年了，但一直不知道有何差異
聽完同事說的，還是掌握不到做法
有點見樹不見林的感覺
說完還是不知怎麼做











今天正好路過書店逛了一下
看到「敏捷與Scrum軟體開發速成」Amazon有4.5顆星的評價
嘖嘖~ 直接買來看

章節安排挺不錯，很順暢的一篇篇讀，也不會太多廢話，有些真的話很多...
從敏捷方法的緣起說起
再強調敏捷的價值觀與原則，不會硬套方法
最後帶入實務做法
感覺讀完就上手了~ 怪不得4.5顆星了~
近期來試一下...

翻譯也挺不錯的，用詞都很到味，可以感覺譯者懂這方面的domain knowledge
譯注也很用心在寫，第一次看過這麼多譯注
某些文化梗也有翻，而有些資料也得花時間找~
真是佛心來著~