发现我们和这个很接近，主要是以 model 的测试为主，controller 和 view 测的比较少，主要流程上进行集成测试，代码·测试保持基本一半左右。

这让 1:1177 的 sqlite 情何以堪哪 http://www.sqlite.org/testing.html

我最近的一个项目，早期测试比例在 1:1.2 左右，现在降到了 1:1。核心 feature 测好之后，后期的小调整就不用再测了。

+1

我在 1:0.8~0.9 左右，偏少。

因为见到很多项目是缺乏测试，所以还没讨论过测试过量。

不要用 Cucumber 符合我一向的想法

我也偏少，基本上只做通过测试，剩下的有问题才测，毕竟一边做，很可以会否定很多东西，否定完后，如果前面测试太多。。。。。那得改到什么时候

看到倒数第二条我就猜是不是 dhh 写的

我也不喜欢 cucumber 比较喜欢 testunit+capybara 的组合

我主要就写 Model 测试

我还愁测试代码太少了～

代码·测试比超过 1:2 就味道不对了，超过 1:3 则臭不可闻 这个到底是说什么意思，，看不懂

1:2 代表有代碼異味 code smell，而臭不可聞呢是 stink，有惡臭的意思，代表你的代碼糟透了。。。

几年前追求测试覆盖率，曾经达到过 1:4，汗呢

主要写单元测试和控制器的测试，而验收测试就比较少写了，感觉太花时间

出来一个反驳的文章 http://js.hu/blog/2012/04/18/testing-woes/

#2 楼 @bhuztez 37signals 这个是针对 rails app 而言的

#15 楼 @allenwei 这个反驳的文章有一点比较明显，AR 不是不重要而是不需要投入太多精力去测试，model 的描述在 RoR 中已经相当清晰简单了，人工 debug 已经足够，少量的 function 测试就可以了。

但是我还是不太理解为什么要抵制 cucumber？有人能帮忙大致解释一下么？

总结的很好

cucumber 很好，只是很多人不大会用而已

#17 楼 @ranmocy 理论上 function test 或者 integration test 可以覆盖用户的行为，但 unit test 在方便开发和调试上还是很有必要的，要不 integration test 出了问题，你都不知道什么地方出的问题，粒度太大。

cucumber 写起来比较麻烦，不过对非程序员的人写 integration test 还是比较友好的，如果都是程序员去写，那用 steak，或者直接 rspec 就好了

非常认同这几条，个人十分玩不转 cucumber，后来干脆不用了。

#20 楼 @allenwei 写起来麻烦是指代码行数多了不少是么？ 对我来说我觉得 cucumber 带来了一种全局观，可以从整体上看清楚都需要什么功能，可以考虑功能间关联和如何抽象。 其实更像是 TODO-List 的感觉。尤其是当你负责一个项目，哪怕只是一个局部功能，cucumber 都可以更好的帮助你整理思路。

rspec 的话个人感觉就是单纯的测试，前提就是整个项目已经设计好了，只是需要完成代码。

#22 楼 @ranmocy 对于 cucumber 的写法有很多争议，基本有两种 1. 用最基本的 step 写下用户的点击行为，这样写程序员会少写不少代码 2. 用描述性的语句写每个 step，这种对非程序员来说非常易读。 不管哪种写法都会增加写程序的负担，毕竟写完 feature 还要写 step 实现

BDD 类型的测试框架都会有全局观，看你怎么去写，没必要一定用 cucumber，重要是的没多少人真正在用 BDD 开发。 BDD driven 出用户的行为，driven 出 TDD，结合起来才是一个好的测试

我也不是反对 cucumber，在我们公司 integration test 就是用 cucumber 写的，提需求的人会写出大概的 cucumber 的每个 feature，每个 step，step 就是语义化的，大家都能看懂的，程序员拿去修实现，cucumber 测试通过后，QA 会重新看写好的这些 feature 是不是满足需求

每个工具都有他适用的范围，没有银弹

写测试先行的代码好比做爱戴套，安全性提升了，但是体验降低了。

用 Cucumber 相当于戴两层套，纯属胡闹。

还是无套来的爽啊 XD

#23 楼 @allenwei 嗯，基本同意。cucumber 更像是一种约束和引导吧，如果习惯 BDD 的话其实纸笔更有效些。

#24 楼 @psvr 不带套的话后来的麻烦事多啊

#24 楼 @psvr 这都能打这么个比方，