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

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

收件人 发送状态 时间 [email protected] 成功到达对方服务器 2012 年 3 月 8 日 18:16(星期四)

是不是搞错了？你给我来封邮件。[email protected]

Rrrr

Ggg

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