日前 Kent Beck, Martin Fowler, DHH 的三強視訊會談 Part V & VI 甫結束並釋出影片 ...
總算為軟體開發界的 TDD 大戰劃下了句點 ...
我恰好這一系列的討論都有空 follow
於是整理本文作為個人筆記，供有興趣的朋友一同討論
# 本文前半部參考 91 前輩先前整理過的 懶人包
# 文長慎入 ... 可能需要 15 分鐘至 1~2 天才能看完這些資料 ...
# 有朋友要幫本文寫懶人包嗎？ => 懶人包的懶人包？？ XDDD
 |
| 圖片引用自 這裡 ，該公司為了紀念 TDD is Dead 將旗下與 TDD 相關的 e-learning albums 組合成 box set 並且限時給予 50% 折扣進行販售 ... |
觀戰前的背景知識
Martin Fowler (Refactoring: Improving The Design of Existing Code 的作者) 有寫過這些文章：- TestDrivenDevelopment - 極短文，僅做概念陳述
- SelfTestingCode - 短文，此概念當初在 Refactoring 一書中就被提出
- UnitTest - 推薦一讀，文章引用很多作者自己寫過的好文
介紹 TDD 的文章：
- wiki - 說明很詳細
- Introduction to Test Driven Development (TDD) - 無程式碼範例，但是概念陳述與相關技術的關係說明頗佳
- 30 天快速上手 TDD - 網路上個人已知最好的中文教學
毋庸置疑地， Kent Beck 的 Test-Driven Development by Example 是了解 TDD 起源的好書：
備註：
如果您對 Testing 毫無概念
可以先到 tutorialspoint 下載 testing 的 電子書 建立基本概念
緣起 ...
（＊ 表示建議閱讀）
4/23
- DHH (David Heinemeier Hansson) 在 RailsConf 2014 演講時，先借由減肥無祕方的例子來暗喻軟體開發不該迷信，之後進而開始抨擊若導入 TDD ，則會為了測 unit test 使得設計出來的架構變糟 ...
- 演講錄影（可切換自動產生的英文字幕）
- DHH 發表 ＊TDD is dead. Long live testing. 一文
- 事後 little lin 發表本文的 ＊中文翻譯
- 事後 xdite 發表 返璞歸真 -- 以最適當的方式設計軟體 （以自己的話詮釋 DHH 想表達的內容）
因為他是 Rails 作者 + 知名軟體公司創辦人 + 暢銷作家 ( rework / remote )
事出必有因，若往前追究
我們可以知道至少從 2012 開始，就有人嘗試把六角架構 (Hexagonal) 帶入 Rails
以解放 application 對 Rails 的依賴
- 2012
- Matt Wynne - Hexagonal Rails
- 講者為 The Cucumber Book 的作者，亦為 Cucumber 的 contributor
- GORUCO 2012 ＊演講錄影
- Hexagonal Rails - Introduction
- Hexagonal Rails: Objects, Values and Hexagons
- 2013
- Jim Weirich on Decoupling from Rails
- 演講錄影 - 以 live coding 的方式示範
而 DHH 在 2013 年初亦發表過 Dependency Injection is not a virtue 一文
可以看出對於該怎麼使用 Rails ，身為作者是有一定的想法
可以看出對於該怎麼使用 Rails ，身為作者是有一定的想法
Part I: 筆戰
4/24
- Jim OKelly 發表 Why I can TDD and why DHH can't 一文
- 認為 DHH breaks shit at the wrong boundaries
- 推薦 ＊Gary Bernhardt 的演講
- 說明自己為什麼喜歡 TDD，是因為只寫小、目的單純、stateless 的 object，且搭配 FP style 進行 programming ...
4/25
- Uncle Bob (敏捷開發、Clean Code ... 的作者) 發表 Monogamous TDD 一文
- 針對 DHH 文章的開頭用詞「Test-First 基本教義」跟相關比喻進行回擊
- 說明 TDD 的好處
- 回應 DHH 使用 integration testing：
- If you can meet my two predicates of trustworthiness and speed, go for it!
- 最後又點出只做 integration test 的問題
- 速度慢（DB, GUI）
- Coverage 較不足
4/29
- DHH 發表 ＊Test-induced design damage
- 聲明 Jim Weirich Demo 的六角架構不適合使用在 Rails 上
- Rails 有跑 persistent console process ，且對於 test case 有 transaction wrap ... ... 所以速度已經快很多
- 說明 controller 就是要拿來跑 integration testing 用的，並且針對 Rails/MVC testing 該怎麼做進行指導
4/30
- Kent Beck 發表 ＊＊RIP TDD
- 本文並沒有回應 DHH 的看法跟觀點，但用反串方式說明 TDD 的存在價值
- 以下為全文截圖
- Uncle Bob 發表 ＊When TDD doesn't work
- 說明 TDD 不適用的情境：
- The physical boundary, and the layer just in front of that boundary that requires human interaction to fiddle with the results.
- The test code itself.
- 說明將 logic 抽出並不會傷害 application：
- 這是 good design
- （有回應 TDD is Dead / Test-induced design damage 的意味）
- DHH 發表 Slow database test fallacy 呼應自己前一篇文章
- Gary Bernhardt 發表 ＊TDD, Straw Men, and Rhetoric 反擊 DHH 新發表的文章
- 引用 DHH 的 Slow database test fallacy 的內容：The classical definition of a unit test in TDD lore is one that doesn't touch the database.
- 作者透過引用相關文獻以說明 TDD 的發展比 Mock 還早，所以早期的 TDD 定義並沒有要求使用 Mock 或是撰寫 isolated unit test ...
- 進而對 DHH 的其他不正確陳述進行一連串的反駁 ...
- 提到自己不滿足於 integration testing 的速度，自己對測試 feedback 回來的需求是 300 ms
- 說明在此情況下對生產力的提升（更專注、快速測試-> 短時間內得到更多 feedback）
- 說明自己對 TDD / test isolation 的看法
5/1
- Uncle Bob 發表 Test Induced Design Damage? 反擊 DHH 4/29 的文章
- 認為 Jim Weirich 的做法 是優雅地 separate concerns
- What I saw was a tightly interwoven mass of rails and business logic being teased apart by a master of his craft. The result was, frankly, beautiful.
- 補充說明 separate concerns 這樣的 design principle 來自 On the Criteria To Be Used in Decomposing Systems into Modules by David Parnas (1972)
Part II: 視訊戰
在筆戰的過程中，其實 DHH 已與 KB (Kent Beck) 及 MF (Martin Fowler) 用 skype 聊過天
最後在 ThoughtWorks 的協助下安排一系列的 google hangout 視訊並且釋出影片
MF 有對這一系列影片做整理並且放在他的 ＊＊部落格 上
（以下懶人包部分摘錄自 MF 的部落格，強力推薦閱讀 MF 整理的重點）
5/9
- Is TDD dead? [Part I]: TDD and Confidence
- ＊錄影 (約 30 分)
- DHH 提出三個問題：
- Unit test/TDD 的定義
- 架構系統若使用 mock 會導致 test-induced damage
- 自己並不 enjoy TDD flow 的流程
- KB 點出要達到對自己的 code 有信心 (confidence) 是 programmer 的目標，若在此共識之下：
- 對他自己來說 TDD 是其中一個能達到這個目的的方法
- 舉出前幾天在 FaceBook hackathon 時混用 TDD 與一般測試開發方法來幫助自己開發的經驗 (目前 KB 在 Facebook 工作)
- DHH 表示自己：
- "...you're not done until you also have tests for a piece of functionality -- I'm completely on board with that."
- 認為 TDD 適用某些地方，但是套用 TDD 並不會讓自己快樂，在某些領域 用 TDD 會是 bad tradeoff (特別是使用大量的 mock)
- KB 回答：
- 自己很少使用 mock、多層 mock 很糟
- 取得 repeatable feedback loop 是重點
- 當發現測試難以撰寫，會先 check 是否是架構上的 design 問題
- MF 補充：
- 是否要撰寫 isolated unit tests 是個人選擇問題 - 當年自己跟 KB 在推 TDD 的時候，還曾被批評沒有寫 isolated unit tests ...
- 是否綁定 TDD 與 isolated unit tests 是派別問題 - 自己認為不該綁
- TDD 是達成 self-testing code 的 approach 之一，如果有其他方式能夠達到，那也很好
- 5/15 （迴響）
- Gary Berhardt 發表 Test Isolation is About Avoiding Mocks
- 引用 KB 在 Is TDD dead 的觀點 nested mock 是不好的，進一步以自己的經驗與例子，闡釋 test isolation 能夠帶來的好處
- Structured programming clarifies control flow; isolated tests clarify coupling.
- 5/19 （迴響）
- Uncle Bob 發表 First
- 引用 DHH 在 Is TDD dead 的觀點 "...you're not done until you also have tests for a piece of functionality -- I'm completely on board with that."，進一步闡述 testing 的重要性與好處，最後反問 .. 既然很重要為什麼不先做 (First)
5/16
- Is TDD dead? [Part II]: Test Induced design damage
- 錄影 (約 30 分)
- DHH 從 Jim Weirich 當初展示的六角架構範例，擷取出 gist ，指出架構上許多不必要的設計
- 程式碼的數量會影響到是否易於改寫
- 每一個中介層會帶來高成本
- 就是因為使用 TDD 所以特別容易引誘人寫出這樣的架構
- KB 指出
- ascribing test-induced damage to TDD was like driving a car to a bad place and blaming the car for it，表示是否需要設計出這些中介層是要被評估的
- MF 補充
- DHH 指出的問題是由於想要 isolation 導致的，而不是 TDD
- 摘錄自 MF 的部落格：
- Kent clarified he wasn't talking about TDD, but about software design in general, it's not about TDD it's about how to get feedback. Thinking about software design is the thing, because it pays off so big when you get a good design insight. Getting these insights isn't about your workflow, it's about things like knowing when to work and when to rest, gathering influences from other places, collaborating with other people.
5/20
- Is TDD dead? [Part III]: Feedback and QA
- 錄影 (約 30 分)
- KB 提出討論 (TDD 的) tradoff 時，有以下幾點要被考量：
- Frequency - 要多快取得 feedback？
- Fidelity - 對於 red/green 這些訊號的準確度要求為何？
- Overhead - 我們願意付出多少代價
- Lifespan - 產品的生命週期為何
- MF 補充我們會希望透過得到 feedback 來得知：
- Is the software doing something useful for the user of the software?
- Have I broken anything?
- Is my code-base healthy?
- DHH 提到TDD 的成功使得:
- 有些人會過度自信而忽略該有的 QA
- 有些人會忽略 cost
- 對於有些情境 (某些 web 應用) 不需要 high reliability
- 99% -> 99.99% reliability 付出的代價很大，應注意臨界
- KB 將討論主題拉回 QA
- Compared to having an effective QA then no-QA is worse, but no-QA is better than the old dysfunctional relationship.
- DHH 提到就算透過 TDD 得到 100% coverage 還是可能有誤，KB 則分享對 Testing 的看法：
- As soon as you think you don't make mistakes any more, that's a mistake, and you stop growing.
5/27
- Is TDD dead? [Part IV]: Costs of Testing
- 錄影 (約 30 分)
- DHH 提到 TDD 易於導致 over testing 的問題
- KB 提到：
- 用 test-first 開發 JUnit 時很順利，無 over testing
- 引用 Herd Derby 的 delta coverage，建議檢視 test 的重要性
- 要勇於丟掉沒有用的 test
- (testing code / production code) 的 ratio 數據容易讓人混淆
- 簡單的系統會有低的比例
- 看情況比例有可能是 10:1 也有可能是 1:10
- MF 補充：
- "you don't have enough tests (or good enough tests) if you can't confidently change the code,"
- "the sign of too much is whenever you change the code you think you expend more effort changing the tests than changing the code."
- DHH 提到有許多人將測試視為文件，甚至重視 testing code 更甚 production code，而忽略了 TDD 中 Refactoring 的重要性，亦忽略追求 clean code 才是重點
- KB 說他最近把部分 production code 丟掉，留下測試進行重寫，並提到：
- would you rather throw away the code and keep the tests or vice-versa? In different situations you'd answer that question differently.
- DHH 說人們無法正確量化 code quality 所以只能量化 testing 的數據，一味追求這些事情只是 honey trap：
- Cucumber really gets his goat - glorification of a testing environment rather than production code
- Only useful in the largely imaginary sweetspot of writing tests with non-technical stakeholders.
- 視訊結束前 DHH 提到 TDD 已經征服各領域，但 MF 不這麼認為
6/4
- Is TDD dead? [Part V & VI]: Answering Questions
- 錄影 (約 60 分)
- 本次會談由三人輪流挑選 google hangout 上的問題，並且回答
- What is an example of an Open Source Project which has "test-induced design damage"? What is an example of a project which does "TDD right"?
- 由 Mike Harris 發問
- DHH 指出 open source 的情境與真實商業專案的情境不一樣，而 TDD 在開發 open source library, framework ... 是有幫助的
- KB 指出 JUnit 是完美的例子，但是是肇因於 java 上極度 clear interfaces 的關係（所以算是特例）
- What could change about the way we write software to make TDD redundant or obsolete for Kent and Martin? What could change about the way that TDD is performed to make it useful or beneficial for David?
- 由 Graham Lee 發問
- KB 引用自己寫的 RIP TDD 表示不會因為難以 TDD 而打算拋掉這項技術
- MF 回答："Some contexts are very suitable for TDD, some contexts less so". And people bring their personality into that context.
- DHH 表示他剛開始使用 TDD 時很喜歡，而嘗試用在所有地方，但是在 MVC 的架構下卻遇到問題 ... 但儘管不用 TDD，達成 self-testing code 仍然是目標
- MF 補充說每個人應該試著嘗試、overuse 以及找到 TDD 能夠運作的情境
- How do you think a lack of (design) experience affects TDD and how do you think TDD affects an inexperienced developer?
- 由 Udor Pavel 發問
- ML 回答：
- 不應比較：有經驗的人 vs 沒有經驗的人 用 TDD 的情況
- 應比較沒經驗的人： 用 vs 不用 TDD 的情況
- it does seem to be advantageous, and creates a self-testing code base which is easier to improve later through refactoring. So tdd gives you a good start point.
- DHH 認為 TDD 在被提出後這十年間，已經被許多人加上其他觀點，當他說 TDD is dead 是指這些改變讓 TDD 變質，所以應該找回初衷
- KB 說：
- TDD isn't dead, but is glad David set fire to it so it could come out like a phoenix.
- DHH 在最後的對談提到：
- 之所以發起 TDD is Dead 是因為人們沒辦法暢談 TDD 不 work 的地方，而被不斷地灌輸一定要 TDD 的觀念。
- ML 做最後的結論：
- 三人對於 self-testing code, TDD 在某些情境下 work 有共識
- 但對 TDD 是否在其他情境下 work 則沒有共識
- 在軟體開發過程，每個人應建立對自己及團隊有效的開發流程，不該盲目的套用技術
- We're not in a codified science, so we have to work with our own experience.
Part III: 不太相關的花絮
5/13
- Tom Stuart 於 Scottish Ruby Conference 2014 投稿閃電秀：The DHH Problem
- 演講錄影 (約 3~4 分)
- 作者提出對於看待 DHH 言行的反思
5/17
- Joe 於 PyConAPAC 2014 投稿閃電秀：BoF is Dead. Long live eating. (PIZZA)
- 投影片
- 內文對 TDD 的暗喻不太正確
- 但演講內容其實是介紹當天的 BoF 活動
Part IV: 戰文心得
DHH 在發表 TDD is Dead .. 一文之後在各界的筆戰中大都處於劣勢
追根究底，是因為他的主要論點只有：
- TDD 使得開發者把重心放在寫 (isolated) unit tests
- 開發者會為了寫 (isolated) unit tests 導致產生不必要的中介層，破壞系統架構
可以看得出來，他攻擊的點在於 (isolated) unit tests
而對於 Test-First 這件事本身沒有提出更有力的批評
更糟的是，當他論述時誤用了一些詞彙跟定義，例如：
The classical definition of a unit test in TDD lore is one that doesn't touch the database.他試圖表達「以前 TDD 導入 (isolated) unit tests 情有可原 ... 但現在已不適用 ...」這樣的論述
但是卻被糾正：其實以前的 TDD 並沒有要求做 isolated unit tests（甚至還因此被人批評）
使得 DHH 的主要論點變得薄弱許多
而即便不聊 TDD 只聊 isolated unit tests
其對系統架構的傷害與否也是未有定論
DHH 認為 Jim Weirich 用六角架構重構 Rails App 是傷害系統架構
但 Uncle Bob 認為這樣很好，因為做到 separate concerns 更能應付變化
我記得 Jim Weirich 在 demo 六角架構時有提到
一般來講他不會對這樣例子的 Application 做這些操作 ...
亦即，對於開發小型的 Rails 應用極有可能 Jim/DHH 的用法是一致的
事實上，若能不帶偏見仔細聽 DHH 發言
他大多數提出的看法和反思對新手是有價值的
這系列戰文/視訊看來，他是扮演黑臉的角色
去把思考不夠透徹的人做 TDD/Testing/Design 時會遇到的潛在地雷挖出來
並透過與 KB / MF 的討論告訴大家
至於是否 TDD is Dead ？答案很明顯 : )
我的結論前半與 KB 一樣，後半與 DHH 原本說的話一樣
- TDD isn't dead, but is glad David set fire to it so it could come out like a phoenix.
- Long live testing.
Part V: 個人經驗
一兩年前初探 TDD 時，最讓我有共鳴的是重視 context 這件事
亦即，有了所謂的使用情境，production code「為何而寫」才會清楚 ...
一陣子之後，我混用 TDD 的概念應用到開發 web API 的使用情境
透過交替撰寫 testing code 與 production code （順序很隨性 XD）
進而讓被釋出的 API 品質提高非常多
但實作上我沒有撰寫所謂的 isolated unit tests
而是真槍假彈地跑 integration tests
事後我才知道，對我負責的系統而言
我的做法偏向 ATDD ...
但實作上卻常遇到問題：上游根本沒有定義使用情境或是定義混亂 ... Orz
藉由這次的 TDD is Dead 大戰
我把看了好久都沒看完的 Test-Driven Development by Example 讀過
並且盡可能把相關文章、影片看過，釐清各方思路進而整理出筆記
雖然花了好幾天的時間，卻也得到海量的收獲
這些所得對新手而言，絕不是學五分鐘 TDD 或是看一兩篇短文論述就能領悟！
最後，附上許多問題 + 個人想法結束本懶人包：
我把看了好久都沒看完的 Test-Driven Development by Example 讀過
並且盡可能把相關文章、影片看過，釐清各方思路進而整理出筆記
雖然花了好幾天的時間，卻也得到海量的收獲
這些所得對新手而言，絕不是學五分鐘 TDD 或是看一兩篇短文論述就能領悟！
最後，附上許多問題 + 個人想法結束本懶人包：
- TDD 會造成 over design 嗎？
- 基本上不會。如果要說的話是造成 over implementation
- 亦即實作上比較費力，但是都還是緊咬著需求
- Kent Beck 曾說過非常貼切的一句話來形容 TDD:
- "Code for tomorrow, design for today." Here's what happens in practice.
- TDD 適合解未知的問題嗎？
- 適合。但前提是 ...
- 在該領域本來就能透過寫 test 驗證答案
- 而且越好寫 Test 越適合透過 TDD 解問題
- 套用 TDD 的 workflow 很像在用數學歸納法解題
- 先去思考 context 再去找 form (推薦訂閱 搞笑談軟工)
- TDD 會導致系統缺乏全局設計嗎？
- Kent Beck 曾舉例：
- "What if I do a paper design for a week, then test-drive the code? Is that TDD?" Sure, it's TDD.
- 我常舉例，只要把手邊的 ToDo list 轉成 ToTest list 就可以開始 TDD 了
- 意指 TDD 的思維不會打壞原本的設計，只是透過思考 context 讓實作更加實用罷了！
- 所以我該馬上導入 TDD 到我的專案？
- 會問這個問題可能是因為
- 還不夠了解 TDD
- 還沒有想清楚自己專案情境
- 建議衝動地想要全面擁抱 TDD 前，思考過 DHH 的論點以避免地雷
- Jim Weirich 介紹的那種六角架構合不合用？
- 懶惰點的回答是 - 看情境
- Jim 有提到一般來講他不會對小程式做這樣的操作 ...
- 我個人其實之前也是以 integration tests 為主，但是這個架構讓人能夠重新思考 procedure/OOP 的概念
- 更深入想想則有很多有趣而值得反思的點：
- Web MVC 是一個怎麼樣的設計？
- 你撰寫的程式碼是 style 偏 procedure 還是 OOP？會怎麼混合？
- 為什麼開發者在 Web MVC 的框架下開發，往往會在系統規模變大時讓 Controller 的部分會變得雜亂？
- 這個時候是不是該抽取出 business logics 或是改變系統的設計？
- 使用框架的初衷跟需求為何？
- 想要全盤 or 部分接受 Rails？
- 如果很不喜歡 Rails 的架構，而花費大多數心力在脫離他？那幹嘛還用它？
- 會有更加友善且同時支持「開發」與「測試」的框架嗎？
- 自己寫一個？(引用自 The DHH Problem )
- 你對 DHH 看法如何？
- 我買過他跟 Jason 合著的書且寫過 心得 ，你認為呢 XD
- 附帶一提看完大戰後，我對於 Kent Beck, Martin Fowler 是感到佩服跟尊敬
- 好在 Uncle Bob 只有寫文章沒有出來視訊（叔叔的文章比較戰 ...）
- 我相信 Kent Beck, Martin Fowler 是本著想釐清問題跟推廣 TDD 的角度來進行視訊
- 所以到底該如何開發 Rails App？
- 呃 ... 我只寫 Python ... lol (魯蛇無誤)
撰文緣由：
我在 5/31 的 Tainan.py 投了一場演講
演講內容從 testing 概念到 unit tests 到 TDD ...
輪到 TDD is dead 系列文的開頭時就過了一個多小時 Orz
最後在講得不清不楚的情況下結束演講
痛定思痛，索性花幾天的時間整理系列文章
希望對當天的朋友、有興趣的朋友有所幫助
台灣各地 Python 社群列表：
Taipei.py - 台北
PyHUG - 新竹
Taichung.py - 台中
Tainan.py - 台南
Kaosiung.py - 高雄
花蓮.py - 花蓮
