PTT職涯區 / Soft_Job (軟體人)

[心得] RIP TDD(BY Kent Beck)

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