1
msg7086 2014-04-19 20:17:14 +08:00 1
跟自动标签的意见一样。「TDD 感觉良好」
当然不一定是非要先写spec再写代码。我个人有很多时候就是先写代码,完了关掉代码开始写spec,最后跑rspec看代码有哪里不对劲。 因为spec也是代码,spec也有可能犯错的。 |
2
yukirock 2014-04-19 20:21:09 +08:00 1
別的不說,學校的作業,先按照評分要求寫好 Test,再圍繞 Test 完成,效率往往很高。
實際上因爲作業提交系統就是一個自動的 Test 系統嘛。 |
3
victor 2014-04-19 20:50:31 +08:00 1
理想是美好的,现实是残酷的。
|
4
jianghu52 2014-04-19 21:37:33 +08:00 1
TDD应该说非常的有效。
但是基于两个前提。1,足够的时间。2.足够有经验的人写test。 尤其是第二条。test其实直接反应的就是你对于程序的理解,如果是那种死都不能把自己变成用户的开发者,你让他写test跟没写没杀区别。 |
5
zxc111 2014-04-19 21:38:59 +08:00 1
由于 Rspec 熟练度的问题,我写测试很慢,而且经常出现先写完功能才记得写测试。
虽然有点慢,但是以后维护起来超爽。 无论是重构,或是 Rails 版本升级然后代码跟着升级,测试覆盖够的话,跑一遍测试哪里有问题一目了然,还是很舒服的。 |
6
lijinma 2014-04-19 22:28:12 +08:00 1
我写nodejs的时候,一般从下面几个角度考虑:
(1)这个项目是不是开源项目?如果是开源项目,没有TDD或BDD,别人很难信任你的代码; (2)项目是私人项目;是不是这个项目将来可能改动的情况比较多,需要重构的几率非常大?如果是,请认真写TDD或BDD; 关于 @jianghu52 说的情况: 1. 如果上面两个条件中的一个条件满足的话,我建议不管时间是否足够,都应该写TDD或BDD,毕竟,你还要维护并重构你的代码,写TDD或BDD从整体角度看,并不会浪费时间,相反,会减少很多坑和时间; 2. 如果是多个人合作的项目,不可能所有的test都是有经验的人写的,项目应该规定一些基本的TDD或BDD需要测试的范围,老大把TDD或BDD重视起来,小弟们也自然会重视,而且要让大家感受到TDD或BDD的美好。 |
7
sethverlo 2014-04-19 23:52:39 +08:00 1
测试的话,忘了在哪儿看过一句话:「测试的多少取决于你的安全感,你觉得写这么多代码正好让你感觉安全,那就够了」
但我从来都是写很多很多测试… |
9
chloerei 2014-04-20 01:10:03 +08:00
先写到觉得烦,再讨论写多少是合适。
|
10
gaicitadie 2014-04-20 01:13:34 +08:00 via Android
如果不是rails项目,TDD还有那么爽吗
|
11
chloerei 2014-04-20 01:14:46 +08:00 2
@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 |
12
RIcter 2014-04-20 01:37:47 +08:00
@gaicitadie 有(`・ω・´)/
最近在和@akinoniku 一起开发东西,基本就是他写好test然后我实现。虽然有时候会有坑。TDD需要写test的人考虑的全面才好(´▽`*) PS.我们是Django |
13
gaicitadie 2014-04-20 09:01:13 +08:00 via Android
@RIcter Django怎么个TDD法啊?貌似没有rspec这么爽的工具。测试速度比rails的快吧,受不了rails测试的龟速。php的测试倒是快,就是写起来不爽
|
14
Perry OP 再自己补充一个文章
http://david.heinemeierhansson.com/2014/tdd-is-dead-long-live-testing.html 文章的题目容易产生误导,本文主要说明了test要倾向于人类行为,比如使用capybara来进行feature test |