如果你想維持測試的習慣，建議在寫實作程式碼之前，先寫測試

有一個程式笑話是這樣的。

『QA工程師走進酒吧，
要了一杯啤酒，
要了0杯啤酒，
要了999999999杯啤酒，
要了一隻蜥蜴，
要了-1杯啤酒，
要了一個sfdeljknesv，
酒保從容應對，QA工程師很滿意。
接下來，一名顧客來到了同一個酒吧，
問廁所在哪，酒吧頓時起了大火，然後整個建築坍塌了。』

然後，我們的 App 就 Crash 了

從這個笑話的 spec 來寫測試，test spec 大概會長這樣

• 測試 case

  • If request is 1, return 1 bottle of beer
  • If request is 0, return 0 bottle of beer
  • If request is 9999999999, return 9999999999 bottles of beer
  • If request is “a dinosaur”, return nil
  • If request is -1, return nil
  • If request is “sfdeljknesv”, return nil

  把測試項目都列出來後，再開始實作程式碼，如果你知道顧客問了「廁所在哪？」會讓酒吧燒起來，就把他寫進測試項目裡面。

  在 iOS 專案上，哪些地方適合寫測試，哪些不適合寫測試

  • 不適合寫測試的地方
    • UI 變化, 使用者真的對一個 button 是不是離右邊界剛好 20 pt 在意? 還是對他按下 button 後的 function 在意?
  • 建議寫測試的地方
    • 格式檢查器,年齡檢查,身分證檢查,email 檢查,密碼檢查
    • 計算器,算時間,算距離,算結果,算邏輯
    • API 中間層和 model, JSON Response 是不對的時候,要保護轉換, JSON Response 是正確的時候要轉換到對應型別, JSON Response 依照需求變更的時候, test case 要做相對應修改.

  附註

  有一種開發法是嚴格的遵守測試先行，方法為 Test Driven Development 簡稱 TDD。雖然這篇文章建議大家先寫測試再寫實作，但在接下來的系列文裡面，並不會完全符合 TDD 的五個步驟。

  

  1 - 先寫測試

  2 - 讓測試 fail

  3 - 開始實作

  4 - 測試通過

  5 - 重構

  因為並沒有完全符合 TDD 的五個步驟，所以我並不會說這篇系列文使用的開發手法是 TDD。