TDD 或是一个 unit 一个 test。

先把整体的架构框架搭起来，把基础功能完善，再补测试，只写功能性测试，

这个其实比不写测试还危险。

#2 楼 @fredwu 求教育。

#3 楼 @hhuai 因为有了 “测试”，会更安心，但是 integration tests 抓不到很多 refactor 带来的 bug。系统开发越久，unit test 越难补。

嗯 写下测试比较安全

其实写 unit test 不需要多长时间。
如果做不到 TDD 话，至少应该是写完一个功能，然后就写单元测试。

我不追求完全覆盖，只要求关键覆盖。

觉得写测试时间太长的原因一是不熟练，二是没有把调试时间一起考虑。

维护别人的项目时候我才会后写测试，自己写都是先写测试。

我以前就是一直觉得写测试麻烦，耗时。 但经过这段时间以后我发现，到了后期节省的时间要比之前花费的多得多。

确实是不太熟练。 #7 楼 @Rei 如果在没有解题思路之前，就把测试写下了，会不会以后我重构时，又影响到测试用例了。 btw,因为我本职不是 web 选手，工作开发从来不搞自动化测试，当然也是测试方案不成熟。主要步骤是开发者本人手工自测再交给测试团队进行测试。所以对这块实践比较少。

#8 楼 @huacnlee 我也是因为想跟随 rails 版本升级，手工测又累，为了以后着想，目前在加测试。

怎么保证你的测试是对的呢？

#9 楼 @hhuai

当脑中有一个大概的设计，觉得应该有一个接口，输出输出是这样子，把这个想法用代码表示出来，这就是一个测试用例了。

然后觉得这个接口太大，需要一些小的处理方法，也把这个方法的输入输出地用代码表示，就是另一个测试用例了。测试用例可以随着想法变更增删。

其实打开终端，敲调试代码的时候，就是在写一次性的测试代码，而且很可惜的是这些代码只用一次就扔了，其实很可能还有用的。

以前学习 Qt 编程，未接触自动测试，也是用了 Rails 才用上了。现在我对前端测试不熟，但也觉得是必须的，像 jQuery 本身是带测试的。前端测试要怎么整理我实践还太少。

#11 楼 @evan 测试是用来检测代码实现是否和想法相符，想法可能是错的，测试也可能是错的，但比什么都没有好。

#12 楼 @Rei 非常好的分享，也就是说并不是先将所有测试写完，而是根据需求一步一步写测试和代码。这点我以前有点误解。因为我看过华为的外包，第一阶段就是将所有的测试用例写完，做出来几个项目都是 0bug 交付的。正常的项目和外包的还是有点不一样，外包所有的需求和功能点已差不多定死了，正常项目还是有些自己发挥的余地。

#14 楼 @hhuai 程序员自己的测试是白盒测试，要灵活。外部需求提供的需求是黑盒，就只定义粗粒度的测试。

我没接触过外包，看你描述是外部接口都定义好了，那就是外部测试了。TDD 主要是讲程序员自己的测试，可以灵活迭代，多写内部测试还是有助于更快达到外部测试的需求。

@hhuai , 如果使用 BDD, 测试代码量大于功能, 很正常的.

我粗粗的看过 the RSpec Book, 尝试着描述一下 BDD.

关键你必须理解这是一种开发方式, 而非测试框架, (只不过初期作为开发方法, 同时后期也可以作为测试框架), 其精髓就是必须先有测试 (或行为), 然后以测试 或行为为驱动, 然后就是自外向内, 又自内向外的反复迭代, 重构的过程.

第一步: 先使用 cucumber 来表述对象之间的外部关系, 即实现 Feature. (这一步, 传统模式,往往都是先通过了内部单元测试, 才进行外部的集成测试. 事实证明, 这种方式在后期是绝对低效的, 尤其是错误涉及到更改单元对象内部 代码),

第二步: 下一步就是针对所有的 feature 定义 step_definitions.

这其中的精髓是: 从外到内, 根据需求添加代码, 而且这些代码要足够简单, 只 需要满足当前迭代就好. 编写 step_definitions 就是一个反复的出错, 添加对应 step_definition 除错的过程. 直到改正所有的跟对象之间的关系有关的 错误, 直到最后只剩下一些逻辑错误, 这时候就该进入 RSpec 迭代了.

第三步: Rspec 相对来说, 更像测试代码. 不过此时的目的是为迭代服务, 而非 测试. 实现对应功能以后, 再返回 Cucumber, 直到实现这个软件的 feature.

我自己也是糊里糊涂.

我直接复制一段介绍:

行为驱动测试和一般测试的最大不同为:

• 根据一个需求, 写出测试驱动代码, 常常叫做 UserStory.

• 运行 Story 测试, 必然是失败的.

• 根据 Story, 来编写代码

• 只满足 Story 所需功能.不多不少!

• 再运行 Story 测试, 完整通过测试.

• 重构现有代码, 使其尽量简单, 高效.

• 再根据新的需求, 写出新的 Story.重复以上过程.

这个循环过程, 常常被称作 red/green/refactor.

对了, @hhuai, 留下你的邮箱. github 稍后再搞, 你要感兴趣, 我先给你发我的 的配置, 你看看.

我也是只写关键测试，只要他能驱动我的开发而确保我的主要逻辑不会出问题就可以了 一开始会觉得慢点，但写好测试的框架后，就快了，这和写代码框架也需要时间一样

没有测试，你根本就没有办法进行重构

#16 楼 @zw963 8863824 at qq.com

@hhuai, 邮件发了哦

#19 楼 @zw963 如果代码不是很私密的话，建个 gist 把链接发过来共享吧

我一直都是推荐 TDD/BDD 的，有时项目太赶来不及写测试后期也要找时间把测试补上，昨天刚写了一篇介绍 TDD 的博文，有兴趣可以去看下 http://zernel.github.com/Technical-Diary/2012/03/07/TDD-practice/

如果不写测试的话，我心里会很不安。

哎 看了 shopqi 才下定决心 把 测试补上 fork 楼上的哈

#20 楼 @camel, 尽快喽. 没有私密问题.

#16 楼 @zw963 哈哈，没收着，能不能重发一次。

#25 楼 @hhuai

啊?? 怎么可能呢? 网易邮箱也会出问题吗 ?

收件人 发送状态 时间 8863824@qq.com 成功到达对方服务器2012年3月8日18:16(星期四)

是不是搞错了? 你给我来封邮件. zw963@163.com

Rrrr

Ggg

求指教下, 我在写个功能, 采用 bdd 方式, 但是卡住了, 感觉写测试的工作量好大...
一个邮件转发的, 根据 to 的地址 (user@host), 要查看 to 的 host 是否在系统注册, 然后要查看 to 的 user 是否是被用户许可的, 接着还要查看 这个用户是否是有效的 (就是是否有续费), 这样要写个测试, 要有 3 对测试, 然后这 3 对测试, 还要去写模拟数据, 感觉没力气下手...
写这个功能, 有种要写 3~6 倍代码量的测试的感觉