这种事吧 不看习惯也要看情况 =__,=

不用 tdd 都不好意思跟人打招呼

#1 楼 @leozwa #2 楼 @ddyy

听你们说的好像是迫于环境才使用 TDD，有点不情愿的样子

@besfan 不一定是先写测试，我是先写代码再写测试，不过最后提交代码还是要加上测试，

#3 楼 @besfan 也不是不情愿吧

我觉得如果是个小 app 需要快速做出来（比如用来做 proof of concept, demo 一类的）那我觉得 TDD 并不是必须的（甚至完全不需要写测试）

根据情况 根据自己对 TDD 的熟悉和适应程度来决定是否 TDD

发现我光顾着扯淡了，没正面回答楼主的问题。现在回答下。 我一般都会写测试，覆盖率应该有 60% 以上。除了状态极好的情况下，才会 tdd。但我会补测试。

哪有那么多人愿意 TDD 的。。。

有个图灵奖的获得者，说，写测试的难度是写代码的两倍。

不严格的 tdd 只要测试和代码可以交叉进行。

测试学习成本也不低，要学习一些概念，怎么写测试用例，怎么 stub（没 stub，根本没办法 TDD），在什么时候 stub。很多东西要学。

而且 TDD 乎还要配合下 BDD。BDD 尽可能的确定下需求，然后再 TDD。

如果当年 DHH 用 TDD，估计就没有 rails 了。测试偏细节，对设计感是有干扰的。

前段时间在 rails 界刮起一股歪风，颇有“阶级斗争 (tdd) 一抓就灵”的趋势，好在现在大部分人都醒悟了。

大部分情况下，你自己感觉最舒适最方便的开发方式就是对的，乔布斯不是说过一句话吗， follow your heart

这种开发流程类的都像搞传销。

有测试就行了，为什么一定要 TDD ?

-------------这世上除了“他爹的 TDD”开发模式，还有“他妈的 TMD”开发，就是 Team Meeting Driven，很多公司有太多太多的会要开了，开会基本上成了每天工作最主要的东西，对于一些管理者来说一星期中居然有 80% 时间都在开会。其实，这么多的会议并不意味着你在管理，只是意味着你对要管的东西完全不知道，需要通过开会来了解。很多会完全是没有议题的，大家坐在一起东拉西扯，非常非常地低效。我通常把这种会叫做“神仙会”，用个流行语来说，就是 Cloud Meeting………… http://coolshell.cn/articles/9156.html#more-9156

我习惯于用测试去验证实现的正确性，同时保证重构或功能修改时的及时反馈，至于测试在先还是测试在后，这取决于你对于你所要实现的东西是不是有清晰的概念，不要让测试成为障碍，同时也不要没有测试。

#12 楼 @shinefine 赞！越是大公司越这样。TMD，Cloud Meeting！

看代码形状

越是锯齿形的，锯齿越深的 如果用了 TDD 就越有利

@knwang
求解释或链接：代码形状是锯齿形的？ 谢谢。

#16 楼 @appell 可能是指 Ruby 那种缩进吧，一个方法里，层峦叠嶂的，说明逻辑复杂，优先精简，精简不了的，写测试保证以后别人修改不会 break。

@pepsin 谢谢。

代码量多了，逻辑复杂了，有测试才能在保证重构的时候不会 break codes。如果测试是为了重构和 regression test, 该不该写就显而易见了。 假设你在修改一处小的地方，那处修改会涉及到其他的行为，难道你要去一一肉测（打开浏览器，输入表格，跳转 etc，如此做 10 次），不如 run 一下测试就知道这样的修改是否有负面影响。 项目越大，越复杂，越需要写测试。 写测试是一本万利的好事，保证了重构的效率和质量。 不过对于写 unit testing, functional testing 还是 integration testing, 个人只针对 model 写 unit test。其他就写 feature tests. 再啰嗦一句 BDD, 如果有了 unit test 和 feature test，bdd 也不是非要的。个人更喜欢 bdd 的思想而不是形式。