Rails 大家在写项目时,是不是写测试,是 tdd/bdd?

hhuai · 2012年03月06日 · 最后由 ruandao 回复于 2015年11月03日 · 4746 次阅读

我从搞python起,一直在接受测试驱动开发引导。

但我有两个疑问,是否都确定这个测试利大于弊?

  1. 时间 我在做一些小项目时,有时会先写测试来驱动,写一阵发现写测试的时间要大于我写逻辑功能的时间了。

  2. 多细 细度的把握,测试写多细,是否真的要具体到每个函数。

我目前的做法是这样,先把整体的架构框架搭起来,把基础功能完善,再补测试,只写功能性测试,不会具体到controller和model. 尝到的一个好处是,可以跟随rails的新版本跟进,升级rails版本后把测试用例一通就差不多了。

大家一起来交流交流,谢谢。

共收到 29 条回复

TDD或是一个unit一个test。

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

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

#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

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

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