作者y2468101216 (芸)
看板Soft_Job
標題[心得] RIP TDD(BY Kent Beck)
時間Mon Nov 2 13:32:20 2015
前言：
本翻譯有翻譯不精準且有自行增添字眼，請邊參考原文對照著看。
https://www.facebook.com/notes/kent-beck/rip-tdd/750840194948847
=============
TDD是一種用測試來進行開發的模式，所以他的本質其實是為了開發而非測試。
Kent Beck(設計模式的先驅者)在RIP TDD裡舉出了8個你應該使用TDD的理由。
1. Over-engineering(過度設計):
EX:
今天你被授命要做一個會員登入的系統，你老闆只要你串facebook登入，結果你多寫了一個google登入。
這樣就過度設計了，程式碼裡不要擺用不到的東西，會造成後面維護上的困擾。
TDD每一個測試都是需求，而你不應該寫需求以外的程式，TDD力求以最簡單的方法讓測試通過。
2. API feedback(介面回饋):
因為TDD會根據使用者的需求寫測試，當你發現 你的介面不敷使用於測試時，就會去修改介面，這會使你的介面越來越貼近使用者。
3. Logic errors(邏輯錯誤):
TDD裡面不會有任何的邏輯(if else)判斷，所以如果出來的結果不符合就是你的method有問題。
而且TDD一次只會有一個測試失敗，所以一定是你剛增加的code有問題。
4. Documentation(文件):
每個工程師都會跟你說他討厭程式沒有文件，但實際上會寫文件的很少，後面會繼續維護的更少了。
TDD的測試即文件，當你看完測試你就會瞭解這隻程式怎用了。
而且如果需求改變，你的測試也會改變，就會很自然地維護它了。
5. Feeling overwhelmed:
標題無關。
TDD的宗旨是先寫測試在開發，意味著即使沒有程式依然可以先寫測試，
6. Separate interface from implementation thinking(從邏輯來實踐獨立介面):
EX:
今天有個需求是串金流API，但是開發API的人說他要等上線前10天才能給你測試。
TDD遇到這種問題時就會做一個介面，測試時實作這個介面，去模擬API的行為。
這樣你就不用因為別人拖延自己的進度。
7. Agreement(同意)
當你把需求解掉了以後，你要如何說服發出需求的人妳已經把問題解決掉了？
顯然用測試是一個好方法。
8. Anxiety(焦慮)
當老闆問你一切是否OK時，TDD可以不用讓你提心吊膽的說OK。
工商廣告時間ＸＤ：
https://skilltree.my/events/mbh
十分推薦，我覺得每個程式設計師都應該聽聽TDD，而91的課淺顯易懂，
絕對讓你滿載而歸。
我本身就是學員之一，聽完有如獲重生的感覺。
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 118.163.30.31
※ 文章網址: https://webptt.com/m.aspx?n=bbs/Soft_Job/M.1446442345.A.17D.html
1F：推 neo5277: 我同期公司最近要做 11/02 13:46
2F：→ allenxxx: 如果測試是自己做...我不會想另外再寫獨立一組功能測試 11/02 13:47
根據我寫的經驗，一個unit test case應該10行內可以寫完。
更何況套一句FB流行的話。
你有想過QA測你的程式的心情嗎？沒有，因為你只想到你自己。
沒有測試的情況下，你敢跟QA保証說沒有任何錯誤嗎？
※ 編輯: y2468101216 (118.163.30.31), 11/02/2015 13:57:41
3F：推 FantasyRyu: RIP TDD：安息吧，測試驅動模式 11/02 13:58
4F：推 Masakiad: 根據我的經驗，一個function平均要2-4個case才有效測試 11/02 14:06
5F：推 Masakiad: 不過說實在自動化測試幫我最多的是開發相關功能與重構 11/02 14:09
6F：→ Masakiad: 的時候 11/02 14:09
TDD的精神:測試即開發。
7F：→ leolarrel: 這篇文是因為一個也是業界高手DHH說"tdd 已死",Kent 11/02 14:25
8F：→ leolarrel: Beck 不爽跳出來說tdd 有啥好處這樣,個人覺得,tdd在國 11/02 14:25
9F：→ leolarrel: 外都已經進入成熟期,並且有很多新理論準備取代tdd,反 11/02 14:26
10F：→ leolarrel: 而台灣才開始風行5~6年,太跟不上腳步了 11/02 14:27
下一篇應該是BDD吧，不過BDD也只不過是給PM看的TDD，另外可以推薦新理論嗎？
我打算有空就翻譯這樣。
※ 編輯: y2468101216 (118.163.30.31), 11/02/2015 14:36:10
11F：→ fgh81113: 有個問題 標題感覺像是說TDD可以走入歷史了 可是內文 11/02 14:53
12F：→ fgh81113: 是再說TDD的東西 11/02 14:54
13F：→ fgh81113: 還是說RIP 是其他東西的簡寫或說其他的模式? 11/02 14:55
樓上不夠鄉民，不懂反串ＸＤ。
14F：→ WenliYang: XDDD 11/02 15:37
※ 編輯: y2468101216 (118.163.30.31), 11/02/2015 15:53:15
15F：推 Argos: 能推廣TDD的話真的很好 但實際狀況卻和理想有所差距 TDD當 11/02 17:07
16F：→ Argos: 然最適合用在「需求完整且清楚」的情況下 但很多情況是需求 11/02 17:07
17F：→ Argos: 根本沒把需求寫清楚 不然就是一改再改 在這種情況下 每改一 11/02 17:08
18F：→ Argos: 測試就得重寫 甚至全部打掉... 還有第一項 不要寫需求額外 11/02 17:09
19F：→ Argos: 的東西？哈哈 要是真的能那樣就好了呢 有時甚至需要RD這邊 11/02 17:10
20F：→ Argos: 幫忙完善需求XD 你沒自己加上G社登入 哪天老闆想到還會過來 11/02 17:10
21F：→ Argos: 怪你 為什麼連這個都沒想到？ 要舉一反三阿～～ 11/02 17:11
22F：→ felixgugu: 我只能說，有時間，我什麼都能符合你的要求 11/02 17:43
23F：推 hidog: TDD不是不好 但是台灣適合TDD的公司很少 11/02 18:10
24F：→ hidog: 在開發產品穩定性上來講 TDD有很多優勢 但是初期開發時間過 11/02 18:10
25F：→ hidog: 長這點 台灣應該很少公司願意採用TDD. 11/02 18:10
26F：→ hidog: 更別說在台灣,規格需求三天兩頭改是常態.... 11/02 18:11
27F：→ landlord: 真的要有對的學習、對的導入方式、對的TDD 11/02 18:32
28F：→ landlord: 大家會體會到，寫起來不會比較慢的... 11/02 18:32
29F：→ landlord: 只是大家對TDD的瞭解不夠深入跟全面... 11/02 18:32
30F：→ bndan: 純推回推文部份...XD 11/02 18:54
31F：推 wuliou: 台灣用TDD就變成測試一天改五次了 11/02 19:08
32F：→ GoalBased: 我會想寫測試，但不會TDD，而且只想針對重點寫測試 11/02 20:22
如果是舊程式的話，其實重點寫一寫測試就好了，新程式或重構再用TDD。
再強調一遍TDD是開發模式，只是他利用測試作為開發工具，一魚兩吃。
33F：推 coronach: 台灣搞TDD最大的問題就是熟悉的人太少，所以很難找到能 11/02 22:07
34F：→ coronach: 建立完整流程的強者QA... 11/02 22:07
我都自己TDD，我初期開發起來穩很多，設計起來快很多。
35F：推 hidog: to landlord...TDD初期會比較慢吧 因為多了test code 11/02 23:00
36F：→ hidog: 他的好處是不容易因為增加功能造成bug,因而在中後期加速 11/02 23:01
37F：→ hidog: 除非test code跟主程式開發切開不同人寫,但是台灣很難 @@" 11/02 23:02
38F：→ hidog: 工作以來認識大部分QA都是不會寫code或者coding不強. 11/02 23:02
39F：→ hidog: 台灣不少老闆只想三個月~半年做完一個專案 注定了TDD難行.. 11/02 23:04
40F：推 landlord: 用對方法，只會快、準、爽，不會慢。 11/02 23:35
41F：→ landlord: 不然就不會這麼多上課完的同學回不去過去的開發方式了 11/02 23:36
42F：→ landlord: 重點是把測試拿來描述需求，而不是驗證功能 11/02 23:37
43F：→ hidog: 就不爭辯了XD 但是我真的沒聽過有人說TDD初期會快的 11/02 23:37
44F：→ landlord: 需求、測試、開發、文件，一氣呵成的開發方法 11/02 23:37
46F：→ landlord: 同意不需爭辯，有問題才需要解決方案的。 11/02 23:40
47F：→ landlord: 沒那需求不需非得TDD不可，它不是萬靈丹，我也不是賣藥 11/02 23:41
推91。
48F：推 lovdkkkk: 語言工具也有差, 不是什麼都跟 VS 一樣有強力工具支援 11/03 08:05
49F：→ lovdkkkk: nodejs 做 TDD 難度大概會高一些... 11/03 08:05
node.js做起來比php簡單（遠目，因為是新語言的關係，mocha.js用起來硬是比
phpunit好用很多。facebook/webdriver的文件寫的就是比nightwatch.js爛。
我最近應該會fork facebook/webdriver的example，2年前的範例到現在都不能用了= =。
※ 編輯: y2468101216 (118.163.30.31), 11/03/2015 09:22:10
50F：→ lovdkkkk: 啊...我指的是 Unit Test, 用 webdriver 測 UI 比較沒差 11/03 11:00
51F：→ lovdkkkk: 我現在也是沒做最基本的 Unit TDD, 只做 ATDD 11/03 11:00
52F：→ landlord: ATDD 才是實務TDD的起手式啊 11/03 11:48
53F：→ landlord: 很多人都一直誤會TDD是從unit test發動，甚至要isolated 11/03 11:49
54F：→ landlord: nodejs ATDD，建議可以玩一下 cucumber+protractor 11/03 11:49
55F：推 lovdkkkk: yes, 起手式就很好用也不太怕因變動花時間, 有空再做細 11/03 11:50