[心得] RIP TDD(BY Kent Beck)

[y2468101216 (芸)]

前言：

本翻譯有翻譯不精準且有自行增添字眼，請邊參考原文對照著看。

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://www.ptt.cc/bbs/Soft_Job/M.1446442345.A.17D.html
推 neo5277: 我同期公司最近要做
→ allenxxx: 如果測試是自己做...我不會想另外再寫獨立一組功能測試
根據我寫的經驗，一個unit test case應該10行內可以寫完。

更何況套一句FB流行的話。
你有想過QA測你的程式的心情嗎？沒有，因為你只想到你自己。

沒有測試的情況下，你敢跟QA保証說沒有任何錯誤嗎？
※ 編輯: y2468101216 (118.163.30.31), 11/02/2015 13:57:41
推 FantasyRyu: RIP TDD：安息吧，測試驅動模式
推 Masakiad: 根據我的經驗，一個function平均要2-4個case才有效測試
推 Masakiad: 不過說實在自動化測試幫我最多的是開發相關功能與重構
→ Masakiad: 的時候
TDD的精神:測試即開發。
→ leolarrel: 這篇文是因為一個也是業界高手DHH說"tdd 已死",Kent
→ leolarrel: Beck 不爽跳出來說tdd 有啥好處這樣,個人覺得,tdd在國
→ leolarrel: 外都已經進入成熟期,並且有很多新理論準備取代tdd,反
→ leolarrel: 而台灣才開始風行5~6年,太跟不上腳步了
下一篇應該是BDD吧，不過BDD也只不過是給PM看的TDD，另外可以推薦新理論嗎？
我打算有空就翻譯這樣。
※ 編輯: y2468101216 (118.163.30.31), 11/02/2015 14:36:10
→ fgh81113: 有個問題  標題感覺像是說TDD可以走入歷史了  可是內文
→ fgh81113: 是再說TDD的東西
→ fgh81113: 還是說RIP 是其他東西的簡寫或說其他的模式?
樓上不夠鄉民，不懂反串ＸＤ。
→ WenliYang: XDDD
※ 編輯: y2468101216 (118.163.30.31), 11/02/2015 15:53:15
推 Argos: 能推廣TDD的話真的很好 但實際狀況卻和理想有所差距 TDD當
→ Argos: 然最適合用在「需求完整且清楚」的情況下 但很多情況是需求
→ Argos: 根本沒把需求寫清楚 不然就是一改再改 在這種情況下 每改一
→ Argos: 測試就得重寫 甚至全部打掉... 還有第一項 不要寫需求額外
→ Argos: 的東西？哈哈 要是真的能那樣就好了呢 有時甚至需要RD這邊
→ Argos: 幫忙完善需求XD 你沒自己加上G社登入 哪天老闆想到還會過來
→ Argos: 怪你 為什麼連這個都沒想到？ 要舉一反三阿～～
→ felixgugu: 我只能說，有時間，我什麼都能符合你的要求
推 hidog: TDD不是不好 但是台灣適合TDD的公司很少
→ hidog: 在開發產品穩定性上來講 TDD有很多優勢 但是初期開發時間過
→ hidog: 長這點 台灣應該很少公司願意採用TDD.
→ hidog: 更別說在台灣,規格需求三天兩頭改是常態....
→ landlord: 真的要有對的學習、對的導入方式、對的TDD
→ landlord: 大家會體會到，寫起來不會比較慢的...
→ landlord: 只是大家對TDD的瞭解不夠深入跟全面...
→ bndan: 純推回推文部份...XD
推 wuliou: 台灣用TDD就變成測試一天改五次了
→ GoalBased: 我會想寫測試，但不會TDD，而且只想針對重點寫測試
如果是舊程式的話，其實重點寫一寫測試就好了，新程式或重構再用TDD。
再強調一遍TDD是開發模式，只是他利用測試作為開發工具，一魚兩吃。
推 coronach: 台灣搞TDD最大的問題就是熟悉的人太少，所以很難找到能
→ coronach: 建立完整流程的強者QA...
我都自己TDD，我初期開發起來穩很多，設計起來快很多。
推 hidog: to landlord...TDD初期會比較慢吧 因為多了test code
→ hidog: 他的好處是不容易因為增加功能造成bug,因而在中後期加速
→ hidog: 除非test code跟主程式開發切開不同人寫,但是台灣很難 @@"
→ hidog: 工作以來認識大部分QA都是不會寫code或者coding不強.
→ hidog: 台灣不少老闆只想三個月~半年做完一個專案 注定了TDD難行..
推 landlord: 用對方法，只會快、準、爽，不會慢。
→ landlord: 不然就不會這麼多上課完的同學回不去過去的開發方式了
→ landlord: 重點是把測試拿來描述需求，而不是驗證功能
→ hidog: 就不爭辯了XD 但是我真的沒聽過有人說TDD初期會快的
→ landlord: 需求、測試、開發、文件，一氣呵成的開發方法
→ landlord: 請見https://goo.gl/ht6JbG
→ landlord: 同意不需爭辯，有問題才需要解決方案的。
→ landlord: 沒那需求不需非得TDD不可，它不是萬靈丹，我也不是賣藥
推91。
推 lovdkkkk: 語言工具也有差, 不是什麼都跟 VS 一樣有強力工具支援
→ lovdkkkk: nodejs 做 TDD 難度大概會高一些...
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
→ lovdkkkk: 啊...我指的是 Unit Test, 用 webdriver 測 UI 比較沒差
→ lovdkkkk: 我現在也是沒做最基本的 Unit TDD, 只做 ATDD
→ landlord: ATDD 才是實務TDD的起手式啊
→ landlord: 很多人都一直誤會TDD是從unit test發動，甚至要isolated
→ landlord: nodejs ATDD，建議可以玩一下 cucumber+protractor
推 lovdkkkk: yes, 起手式就很好用也不太怕因變動花時間, 有空再做細