什么时候需要增加测试

当你敲完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 自己的测试没暴露出来，先改测试吧

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

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

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

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

http://blog.8thlight.com/uncle-bob/2012/01/11/Flipping-the-Bit.html

上面中心观点和 #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 赞一个，非常精辟

#22 楼 @knwang 专业！

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

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

#22 楼 @knwang

太赞了!!! 精辟!!!