從 Build Fake Data 開始的 TDD 開發流程 - 有效的減少除錯與開發時間

講了 N 次的 TDD

總地來說**「TDD 能有效減少開發時間 & 降低 Bug 發生頻率。」**

在這邊簡單舉一些 TDD 的優點 ↓

• 先整理過的 Test Target 能幫助減少 Over Design 與未確認規格。
• 已經完成的功能可以透過 Test 來確保重構或是其他變更時舊有部分可以正常執行。
• 構思 Test 的過程中可以列舉出 Code 可能遇到的所有問題可能性，確保思考的完整度。
• 可以被抽離測試的功能意味著程式碼的耦合度低，重用性高，架構方向沒有問題。
• 減少開發途中手動觀測執行結果的等待時間。

畢竟這篇文章並沒有要盡全力解說 TDD，有興趣的朋友們可以參考、關於 TDD 的一些介紹文章：30天快速上手TDD、關於BDD/TDD的三大誤解

而其實這篇文章的起頭是因為「重構」而且沒有寫 Unit Test 所埋下的隱憂開花結果引起過錯！所以有 Test 很重要！有 Test 超重要！

凡事都有個起因，而事情是這樣的

最近公司在將 APP 舊的 UI 翻新，同時開發新的功能，而因為新功能內容跟舊的功能內容完全相同，所以透過人工檢查就容易因為以往的經驗來推測結果，而忽視了問題發生的可能性，既然是因為體感與輕忽所引起，那麼開發者本身也無可避免，像是我自己就踩了幾次自己所留下來的雷。
舉個之前犯錯的經驗來當範例。

自爆雷案例：不知道到底有沒有換的圖片

經過重新設計之後，我們 pipimy 的廣告格式改為在 Web 上常見，大家所熟識的 Carousel

開發為基本功能，確定可以滑動之後，經過 Code Review 之後交給其他同事測也沒有問題，沒想到上版本之後才發現在切換類別時需要重新取得廣告內容的功能缺了！

明明缺了功能，卻到底為什麼大家都沒有發現！？

「嗯？不對啊...怎麼記得好像沒有測到這個問題？」一邊在腦子找尋蛛絲馬跡，一面碎碎念打開 Charles 比較舊版 App 跟新版 App 的差異才發現原來問題出在「在更新成新版前切換不同類別 API 所提供的 image url 完全沒有變動」因為在不同的類別下都是同樣的廣告，所以在更新後切換類別廣告沒有動也是很正常的。

其實對於這個案例來說最嚴謹的測試流程應該是得

1. 設定廣告內容為 1 個
2. 下拉更新 & 測試點擊 & 檢查廣告內容是否正確
3. 設定廣告內容為 2 個
4. 下拉更新 & 測試點擊 & 檢查廣告內容是否正確
5. 設定廣告內容為 N 個 ( N 為適當次數以假設複數內容皆無問題 )
6. 下拉更新 & 測試點擊 & 檢查廣告內容是否正確
7. 切換不同類別檢查廣告內容是否變更，回到 1 步驟

不過光是重複同樣動作設定廣告內容這件事對於測試人員來說就是一件非常浪費時間的事情了，再說身為 iOS 開發人員，我並沒有後台設定管理權限沒辦法自己有事沒事就去隨便更動內容，一需要測試的時候就去麻煩後端設定光是往返不計中斷工作的時間成本就很高，跑 Test 的方式無庸置疑的能節省掉這些時間上的浪費，可以更專注於其他工作上。

在這邊必須先提一下我們目前公司內現在專案 Coverage 不到 10%，既有的 Code 也說實在不少，補上那些 Test 需要心力，加上開發新功能的時程考量下，就會重複考慮是否真的需要補 Test 跟 寫新功能跑 TDD，但實際上當然是可以越早開始越好。

所以可以的話還是建議新 project 就開始跑 TDD，但不建議程式新手一頭栽入，你會發現試圖去了解 Unit Test 是什麼、如何寫的時間效益反而拉慢專案進程。

UI Test 小試身手 ( 以 CHCarouselView 做範例 )

測試更換 CarouselView 的內容