测试 什么时候需要增加测试

zlx_star · 2012年08月29日 · 最后由 zw963 回复于 2012年09月05日 · 3717 次阅读

项目已经有了一定规模了,现在团队开始关注测试。

现在我们想制定一些团队规范:

  • 什么时候需要增加测试
  • 什么时候需要修改测试,什么时候不需要修改测试(关于测试质量)
  • 如何审查测试
  • 。。。

请有经验的大牛分享一下经验

什么时候需要增加测试

当你敲完rails new **后,当然你也可以严格按照 TDD

什么时候需要修改测试,什么时候不需要修改测试(关于测试质量)

当测试不通过的时候。

如何审查测试

有新代码修改必须附带测试,否则 ignore。 我一般除了 view 不写测试 (有集成测试),其它尽量都覆盖。

一开始写测试可能有点慢,但熟练后就很快了。 写不写测试更多和团队氛围有关,大家都写,你自然会写。

当想打开终端调试的时候,就应该写测试,有一定规模已经晚了。不过 Ruby China 也是后补的测试。

TDD 好是好,但是有的时候确实因为懒,所以···

这个话题内容很多。从工具的角度来说,可以考虑上 rails_best_practices,先从代码质量入手。 https://github.com/railsbp/rails_best_practices 单元测试要看程序员的积累,练习加实践是最好的。这里测试的目的有两个:

  1. 业务逻辑是否正确,有时根本测不到,无外乎就是对边界,正常值校验。一个 case 对一个测试,不要写太多了,如何取舍看经验。
  2. 代码质量是否健壮,体现在代码规范,语法错误,最佳规范。其实用工具就是搞测试,不用自己写,或者说参考一些优秀的 metric 工具写一些 mashup.

集成测试,什么白盒,黑盒,看团队规模。太小,就用 rails 自己生成的框架去写。如果团队有专人做 QA,那就让他们去折腾吧。有团队喜欢用 python,bash 去做。

#1 楼 @camel 很有道理,这个团队氛围有关系。 现在我们想找出一些情况,比如:

  • rails new * 之后
  • modify model 之后
  • modify route 之后

然后作为团队的约定,大家都遵守这个约定,就能形成一些约束力,慢慢的就有氛围了。

#4 楼 @xds2000 rails_best_practices 这个已经在使用了,但是感觉作用不大。

难道一般的流程不是:原型 -> 设计 -> 测试 -> 开发

@zlx_star 能分享一下你在使用 rails_best_practices 的预期目标吗?或者说,你为什么感觉它没用?你需要在什么地方加测试。

#8 楼 @xds2000 我用 rails best practices 和 brakeman 就是为了检查自己疏漏的地方。不会按每个分析结果去改。。效果还不错。

rails best practises 可以定制过滤检查项目,可以扩展,所以我很奇怪为啥@zlx_star 说作用不大。

@hooopo 工具么,能用多少功能就用多少,关键能裁剪就棒。rails_best_practises 就支持这个架构,所以我在代码质量这一块,很看好它,就是名字有点直白。

还有就是发现 bug 的时候,第一件事不是立刻去修,而是想想为什么这个 bug 自己的测试没暴露出来,先改测试吧

其实可以反思一下这个标题——“什么时候需要增加测试?”,乍一看很奇怪,合格的工程师都要对自己的工作进行测试,所以无所谓增加测试,这个问题要问的其实是 “什么时候需要增加自动化测试”

这么一想你就明白了,所有的自动化工作都可以这么归纳——“当人肉成本不足的时候就进行自动化”

所以首先严格要求团队成员通过测试确保质量,然后培训或者提醒他们——测试的手段包括自动化,其它事情由开发人员决定就可以了,当他发现回归测试是一个噩梦的时候,合格的程序员自然会添加自动化的工作

具体落实起来要多考虑一个因素,有些事情不做不是因为不重要,而是人手不足,此时考虑自动化吧

上面中心观点和 #12 楼 @fsword 相反 - 人肉成本永远不足。 项目永远有下一个特性等待开发,永远有下一个项目 - 当然除非在官僚的大公司里面。

用这样的标准来看是不是写测试的结论总会是倾向不写,再等等,而越到后来追写测试越困难,测试质量也越差。

好的测试是代码设计的保障,后写测试就已经会失掉一半的意义了

@knwang 点的好。@fsword 你的假设,“合格的工程师都要对自己的工作进行测试,所以无所谓增加测试”。我刚进入 Ruby 开发项目时,就不会写测试。我不知道怎么写,这是真的。并且项目做了一个又一个。后来在面试过程中发现,很多 Ruby 程序员和我一样都是半路出家或自学,根本不会写测试。能把 unittest 写的很熟练的,最多 20%。如果我对测试不熟悉,我也会这么问:什么时候加测试合适? 所以我同意@knwang 给的文章的观点,对于要不要加测试的观点,直接就跳过去,把重心放在怎么写。如果不会写,就去拿 ruby-china 源代码练习去。

#10 楼 @xds2000 我们现在还只是使用它的最基本功能,所以感觉好处不是很明显。

#11 楼 @davidqhr 这倒是和我自己的想法很相似

#12 楼 @fsword 你说的是测试的另一个方面。 我的意思是:找出几种特殊的情况下,我们明确表示需要添加测试。 毕竟如果所有的 MVC 部分都添加测试的维护代价的确很大。

#15 楼 @xds2000 说的对,我们现在就是决定要加测试,正在想什么时候增加测试合适。但是苦于经验不足,所以想请教一下有经验的人。

#18 楼 @zlx_star 我明白你的意思,所以才这么回答。 实际上,要提高自动化测试的 IOR,先要问问它是干什么用的,我的建议是换一下思路:如果不用自动化测试,你需要人工做哪些事情才能对系统的质量放心,然后考虑自动化的成本,这样你自己就会明白应该添加哪些自动化测试。

反过来,如果你平时自己并没有手工验证一下代码正确性,那么可能意味着这个地方的质量你是特别不关心,结论你懂的。

再次强调一下,具体做事的时候要多考虑一个因素,有些事情不做不是因为不重要,而是人手不足,当自动化是一个选择的时候,一些事情也许可以提上议事日程

其它具体的建议往往和项目类型相关,你可以参考,但是恐怕不适合简单照搬

注意:我并没有去可以扣字眼,如果有冒犯之处,请之言。我们是讨论技术,不必客气。

@fsword 跑题了,请不要扩展话题而不讲实际问题。 楼主问 “什么时候需要增加测试”,你在 20 楼回答 “实际上,要提高自动化测试的 IOR,先要问问它是干什么用的,我的建议是换一下思路” 。what's up? 你把问题直接扩展了,“自动化测试” 完全和 “什么时候需要增加测试” 是不对路的回应。难道我理解有误。

@zlx_star 前面@knwang 已经提供了很好的参考 .观点已经很明确: 1.没有借口,开项目就要写测试,不会写,可以学高手的代码。向高手请教。 2.没有借口,直接去做测试的事情。 3.没有借口,直接去做测试的事情。 4.没有借口,直接去做测试的事情。

其实这里有个商机,提供企业级测试培训。

#22 楼 @knwang 赞一个,非常精辟

这两天 DHH 的一个 tweet,是 kent beck 回复的 stackoverflow 上面的一个问题。 http://stackoverflow.com/questions/153234/how-deep-are-your-unit-tests

讲的很好,特别是能打破一些人对 TDD 的迷信。 意思和@knwang 差不多,但对 TDD 动机的描述更清晰一些。

#22 楼 @knwang

太赞了!!! 精辟!!!

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