大家是怎么看待 TDD（Test-driven development）的？

[Perry]

最近在treehouse学习Rails，对TDD感觉良好：使用Rspec先完成test然后再完成后续的功能，觉得这样写出的App更易维护，但是同时大量的test延长了开发时间。尤其是对有一点代码洁癖的我，总是需要很多时间把一个test做好。

[msg7086]

跟自动标签的意见一样。「TDD 感觉良好」

当然不一定是非要先写spec再写代码。我个人有很多时候就是先写代码，完了关掉代码开始写spec，最后跑rspec看代码有哪里不对劲。

因为spec也是代码，spec也有可能犯错的。

[yukirock]

別的不說，學校的作業，先按照評分要求寫好 Test，再圍繞 Test 完成，效率往往很高。
實際上因爲作業提交系統就是一個自動的 Test 系統嘛。

[victor]

理想是美好的，现实是残酷的。

[jianghu52]

TDD应该说非常的有效。
但是基于两个前提。1，足够的时间。2.足够有经验的人写test。
尤其是第二条。test其实直接反应的就是你对于程序的理解，如果是那种死都不能把自己变成用户的开发者，你让他写test跟没写没杀区别。

[zxc111]

由于 Rspec 熟练度的问题，我写测试很慢，而且经常出现先写完功能才记得写测试。
虽然有点慢，但是以后维护起来超爽。
无论是重构，或是 Rails 版本升级然后代码跟着升级，测试覆盖够的话，跑一遍测试哪里有问题一目了然，还是很舒服的。

[lijinma]

我写nodejs的时候，一般从下面几个角度考虑：

（1）这个项目是不是开源项目？如果是开源项目，没有TDD或BDD，别人很难信任你的代码；
（2）项目是私人项目；是不是这个项目将来可能改动的情况比较多，需要重构的几率非常大？如果是，请认真写TDD或BDD；


关于 @jianghu52 说的情况：

1. 如果上面两个条件中的一个条件满足的话，我建议不管时间是否足够，都应该写TDD或BDD，毕竟，你还要维护并重构你的代码，写TDD或BDD从整体角度看，并不会浪费时间，相反，会减少很多坑和时间；
2. 如果是多个人合作的项目，不可能所有的test都是有经验的人写的，项目应该规定一些基本的TDD或BDD需要测试的范围，老大把TDD或BDD重视起来，小弟们也自然会重视，而且要让大家感受到TDD或BDD的美好。

[sethverlo]

测试的话，忘了在哪儿看过一句话：「测试的多少取决于你的安全感，你觉得写这么多代码正好让你感觉安全，那就够了」

但我从来都是写很多很多测试…

[Perry]

@sethverlo 我要写很多测试，有时候测试代码是被测试的代码的三倍

[chloerei]

先写到觉得烦，再讨论写多少是合适。

[gaicitadie]

如果不是rails项目，TDD还有那么爽吗

[chloerei]

@Perry Code-to-test ratios above 1:2 is a smell, above 1:3 is a stink.

http://signalvnoise.com/posts/3159-testing-like-the-tsa

[RIcter]

@gaicitadie 有(｀・ω・´)/

最近在和@akinoniku 一起开发东西，基本就是他写好test然后我实现。虽然有时候会有坑。TDD需要写test的人考虑的全面才好(´▽｀*)

PS.我们是Django

[gaicitadie]

@RIcter Django怎么个TDD法啊？貌似没有rspec这么爽的工具。测试速度比rails的快吧，受不了rails测试的龟速。php的测试倒是快，就是写起来不爽

[Perry]

再自己补充一个文章
http://david.heinemeierhansson.com/2014/tdd-is-dead-long-live-testing.html
文章的题目容易产生误导，本文主要说明了test要倾向于人类行为，比如使用capybara来进行feature test