作者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/cn.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