01｜TDD演示（1）：任務分解法與整體工作流程
測試驅(qū)動開發(fā)，顧名思義，就是將軟件需求轉(zhuǎn)化為一組自動化測試，然后再根據(jù)測試描繪的場景，逐步實現(xiàn)軟件功能的開發(fā)方法。
TDD 的基本原則
為了讓我的演示更有針對性，有些基本原則你需要先了解一下。TDD 的創(chuàng)始人 Kent Beck，在他的傳世大作 Test-Driven Development by Example 的開篇中給出了 TDD 的基本原則：
- 當且僅當存在失敗的自動化測試時，才開始編寫生產(chǎn)代碼；
- 消除重復。
不過在今時今日，我認為第二條應該改為“消除壞味道（Bad Smell）”。畢竟重復僅僅是一種壞味道，還有很多不是重復的壞味道。
那么根據(jù) TDD 的基本原則，Kent Beck 將開發(fā)工作分成了三步，也就是后世廣為流傳的測試驅(qū)動開發(fā)咒語——紅 / 綠 / 重構(gòu)（Red/Green/Refactoring）：
紅：編寫一個失敗的小測試，甚至可以是無法編譯的測試；
綠：讓這個測試快速通過，甚至不惜犯下任何罪惡；
重構(gòu)：消除上一步中產(chǎn)生的所有重復（壞味道）。
然而紅 / 綠 / 重構(gòu)循環(huán)僅僅關注單個測試這個層面，它沒有回答測試從何而來。于是很多嘗試采用 TDD 的人都卡在了第零步：我該寫哪些測試？于是在 2006 年前后我總結(jié)了任務分解法，將任務列表作為 TDD 的核心要素。
任務分解法的步驟如下：
大致構(gòu)思軟件被使用的方式，把握對外接口的方向；
大致構(gòu)思功能的實現(xiàn)方式，劃分所需的組件（Component）以及組件間的關系（所謂的架構(gòu)）。當然，如果沒思路，也可以不劃分；
根據(jù)需求的功能描述拆分功能點，功能點要考慮正確路徑（Happy Path）和邊界條件（Sad Path）；
依照組件以及組件間的關系，將功能拆分到對應組件；
針對拆分的結(jié)果編寫測試，進入紅 / 綠 / 重構(gòu)循環(huán)。
那么 TDD 的整體工作流程如下圖所示：
命令行參數(shù)解析
我們中的大多數(shù)人都不得不時不時地解析一下命令行參數(shù)。如果我們沒有一個方便的工具，那么我們就簡單地處理一下傳入 main 函數(shù)的字符串數(shù)組。有很多開源工具可以完成這個任務，但它們可能并不能完全滿足我們的要求。所以我們再寫一個吧。
傳遞給程序的參數(shù)由標志和值組成。標志應該是一個字符，前面有一個減號。每個標志都應該有零個或多個與之相關的值。例如：
-l -p 8080 -d /usr/logs
“l(fā)”（日志）沒有相關的值，它是一個布爾標志，如果存在則為 true，不存在則為 false。
“p”（端口）有一個整數(shù)值，“d”（目錄）有一個字符串值。標志后面如果存在多個值，則該標志表示一個列表：
-g this is a list -d 1 2 -3 5
"g"表示一個字符串列表[“this”, “is”, “a”, “l(fā)ist”]，“d"標志表示一個整數(shù)列表[1, 2, -3, 5]。
如果參數(shù)中沒有指定某個標志，那么解析器應該指定一個默認值。例如，false 代表布爾值，0 代表數(shù)字，”"代表字符串，[]代表列表。如果給出的參數(shù)與模式不匹配，重要的是給出一個好的錯誤信息，準確地解釋什么是錯誤的。
確保你的代碼是可擴展的，即如何增加新的數(shù)值類型是直接和明顯的。
API 構(gòu)思與組件劃分
利用Options注解來簡化設計，API風格更加友好，有點門檻。我查一下Go語言是怎么支持的。
這并不像很多原教旨主義 TDD 實踐者所推崇的那樣，完全依賴重構(gòu)而不去做設計。然而以我二十年來實踐 TDD 的經(jīng)驗來看，理解需求，并通過測試構(gòu)成高效的節(jié)奏，是有效實施 TDD 的前提。特別是在有其他團隊成員的情況下（結(jié)對或項目組），更需要如此。
內(nèi)容來源：極客時間《徐昊 · TDD 項目實戰(zhàn) 70 講」》https://time.geekbang.org/column/article/494207
