背景：
- 重新閱讀了以下 可以引發思考 的 陳年老文
之所以要 “叕” 談 TDD， 除了上述背景，也是因為自己工作4年來，雖然經常聽到 TDD，但著實沒有“完整” 的在項目上實踐過它。直到最近打算在當前的交付項目上實踐，才又重新審視它，以求回答下列問題：
在逐一回答這些問題之前，先說我對 TDD 這種實踐的 觀點：
- TDD 是確保 Dev 在編寫代碼時，處于 對需求保持 “清醒（Obvious）” 狀態 的方式之一，但并非 唯一 方式
- TDD 中的測試（T）要面向業務需求，而非代碼實現
- TDD 是一種 快速， 可復用 的 反饋獲取 方式，而非唯一方式
- 如果能 不用 TDD 并做到上述 3 點，那么不 TDD 也沒問題。
何為 TDD
在工作的這 4 年來，我對于 TDD 的認識也在不斷變化，現在看來，這種變化的趨勢 是 從 關注實踐形式 向 關注實踐目的 的演變。
那么回到這個問題，Wikipedia 上看到的 解釋 如下：
Test-driven development (TDD) is a software development process relying on software requirements being converted to test cases before software is fully developed, and tracking all software development by repeatedly testing the software against all test cases. This is as opposed to software being developed first and test cases created later.
ps: 我沒有采用百度百科給出的解釋，因其有局限性。它將 Test 縮小到了 Unit Test, 這并不貼切, 我認為測試驅動開發的測試應和測試金字塔相關，可能涉及多層。
我認同這里從 TDD 的 實踐形式 角度給出了答案：
- 將 需求 轉化為 測試用例
- 測試 先于 開發
- 所有的 產品代碼 都能被 反復運行 的 測試 所檢測
在上述的實踐形式中，隱藏了這樣兩個關鍵點：
- 需求轉化為 測試代碼 要先于 產品代碼
- 所有的 產品代碼 都會被 測試代碼 覆蓋
在邏輯上，1和2 之間是因果關系。
遺憾的是，大多接觸 TDD 的新人，都會更看重 結果（2），并且結果也更容易被一些輔助工具所衡量。但是，產生結果的原因（1），卻經常被忽視，因此產生了一些”奇怪“的疑問：
- 單元測試的粒度要多細？
- 測試覆蓋率多少才算達標？
- 應該關注行覆蓋率，還是分支覆蓋率？
當 開發者 開始關注 將需求 直接 轉化為 測試用例代碼 時，上述的所有問題都會被迎刃而解：
- 需求所對應 的 成功用例、失敗用例、需要考慮的邊界條件等等，所有的這些用例可能會被分散在測試金字塔的不同層，其粒度也就結合不同層的關注點被劃定了。
- 當測試用例已經將所有需求都覆蓋到了，那么能通過所有測試的產品代碼的 覆蓋率 還重要嗎？
下一篇《“叕”談TDD（二）--- 為何TDD》中，我將從TDD的實踐目的角度給出我的看法。
