测试 37signals 测试七忌

dotnil · 2012年04月17日 · 最后由 heliang7 回复于 2012年07月26日 · 6103 次阅读

据说今晚 Ruby Tuesday 杭州的话题是测试,可惜我最近都要忙项目。赶巧看到 37signals 也发博文聊测试(http://37signals.com/svn/posts/3159-testing-like-the-tsa),就顺便翻译一下它提的测试七忌。

  • 不要以 100% 覆盖率为目标。
  • 代码·测试比超过 1:2 就味道不对了,超过 1:3 则臭不可闻。
  • 如果测试占用了你超过 1/3 的时间,那你很可能就没搞对。如果超过一半时间,那你肯定弄糟了。
  • 不要测试标准的 Active Record 的关联、验证或者 scope。
  • 把集成测试留到对独立元素们做集成出现问题时在搞(也就是说,可以单元测试的,就不要做集成测试)。
  • 不要用 Cucumber,除非你生活在梦幻之城,那里的非程序员们要写测试(如果你在那儿,请务必给我寄一瓶仙境之沙)。
  • 不要强迫自己对每个控制器、模型与视图都测试先行(我一般是 20% 测试先行,80% 先上车后补票)

原文:

  • Don’t aim for 100% coverage.
  • Code-to-test ratios above 1:2 is a smell, above 1:3 is a stink.
  • You’re probably doing it wrong if testing is taking more than 1/3 of your time. You’re definitely doing it wrong if it’s taking up more than half.
  • Don’t test standard Active Record associations, validations, or scopes.
  • Reserve integration testing for issues arising from the integration of separate elements (aka don’t integration test things that can be unit tested instead).
  • Don’t use Cucumber unless you live in the magic kingdom of non-programmers-writing-tests (and send me a bottle of fairy dust if you’re there!)
  • Don’t force yourself to test-first every controller, model, and view (my ratio is typically 20% test-first, 80% test-after).

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

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

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

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

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

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

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

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

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

我主要就写 Model 测试

我还愁测试代码太少了~

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

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

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

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

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

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

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

匿名 #18 2012年04月22日

总结的很好

匿名 #19 2012年04月22日

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 这都能打这么个比方,👅

需要 登录 后方可回复, 如果你还没有账号请 注册新账号