08｜TDD中的驅(qū)動（1）：驅(qū)動的極限是什么？
測試驅(qū)動開發(fā)的核心要點：單元級別功能測試能夠驅(qū)動其對應(yīng)單元（功能上下文或變化點）的外在功能需求关带。而對于對應(yīng)單元之內(nèi)功能的實現(xiàn)凳鬓，測試就沒有辦法了魁亦。
[圖片上傳失敗...(image-151407-1674484392920)]
比如上面演示的視頻中虚吟，Args.parse 是一個大的功能上下文。按照我們的實現(xiàn)思路怠肋，我們將它分解成了一個小的功能上下文：將參數(shù)列表分解為映射敬鬓。那么我們可以將參數(shù)列表分解放入另外一個單元（Args.toMap)，對它進行測試笙各，從而驅(qū)動它的實現(xiàn)钉答。
也就是說，單元級別功能測試無法驅(qū)動小于其測試單元的功能需求杈抢，也無法驅(qū)動單元內(nèi)的實現(xiàn)方式数尿，需要進一步拆分功能上下文才可以。而指引功能上下文拆分的方式有很多惶楼，比如有不同的實現(xiàn)思路右蹦、架構(gòu)等。
TDD 的極限
曾經(jīng)有些人希望通過構(gòu)造難以用測試驅(qū)動出實現(xiàn)的需求鲫懒，來證明 TDD 不是一種有效的開發(fā)方法嫩实。對于這些人，我都懶得回應(yīng)窥岩。
第一，是因為這樣的需求一點兒都不難構(gòu)造宰缤；
第二颂翼，TDD 并沒有宣稱它是所有開發(fā)問題的答案，所以找到一個反例又能說明什么呢慨灭？
第三朦乏，TDD 的效用在于將研發(fā)過程工程化。
那么無法通過 TDD 有效實現(xiàn)需求氧骤，也只意味著這類問題不能有效工程化而已呻疹。排除一個錯誤答案，并不代表能找到正確的答案筹陵。
測試驅(qū)動開發(fā)的主要關(guān)注點在于功能在單元（模塊）間的分配刽锤，而對于模塊內(nèi)怎么實現(xiàn)镊尺，需要你有自己的想法。
當(dāng)然 Kent Beck 說得更直接：TDD 可以提高效率并思，但不能避免愚蠢庐氮。
小結(jié)
測試驅(qū)動開發(fā)到底驅(qū)動了什么：功能在單元（模塊）間的分配。我們也講了宋彼，測試驅(qū)動開發(fā)在什么地方會失去驅(qū)動力：單元（模塊）內(nèi)的實現(xiàn)方式弄砍。
那么很有意思的事就來了，從“驅(qū)動”的角度來說输涕，TDD 實際上并不是一種編碼技術(shù)（Coding Technique）音婶，它無法幫助實現(xiàn)你不會寫的代碼卜高，你必須要知道如何實現(xiàn)這些功能得滤；但是一旦你明確了要實現(xiàn)的功能，并且知道要怎么實現(xiàn)恨锚，TDD 可以幫助你更好地將功能放置到不同的單元型奥。
也就是說瞳收，TDD“驅(qū)動”的是架構(gòu)，因而實際是一種架構(gòu)技術(shù)厢汹。是的螟深，這正是我們講的編碼架構(gòu)師（Coding Architect），也是真正的實干型而非 PPT 型架構(gòu)師（當(dāng)然你可以省略地講烫葬，這是真正的架構(gòu)師）界弧。這也是為什么 TDD 也被看作 Test Driven Design。當(dāng)然搭综，我覺得 Test Driven Development 其實描述得更全面垢箕。
