不用 Cucumber 也可以做验收测试，用 capybara 之类的工具整合 rspec 等测试框架就行了。

Cucumber 写出来的东西如果没有非程序员来阅读，感觉就没必要专门引入这个东西了。不过我必须承认自己没用过 Cucumber，不是特别清楚这玩意的优势何在（除了普通人可读的 Gherkin）。

关键是我个人认为 Cucumber 可以建立一个对业务需求全局的概念，然后再逐步推进。 验收测试是最后的，如果把黄瓜做为验收测试那是杀鸡用金刀了

如果不是特别的有时间或者是有专人，没必要 cucumber, inside out 的增加测试覆盖其实更好。TDD 不比 BDD 差多少。

你的意思是需求在我心中，走一步看一步； 请原谅我的语气

#4 楼 @golden05 哈哈，那你很赞同瀑布式开发？

＃5 楼 有道理， 但我主要是觉得在开始构思一个系统是，主要都是一些概念，某些比较虚，这个时候就写一些 model 的测试根本不可能，只能借助于黄瓜逐步建立起一个完整的需求文档

#6 楼 @golden05 所以你面对的问题其实是代码层面的设计：应该抽象建立出哪些 model，每个 model 的责任分别是什么，这些 model 间怎样交互。

我感觉这些事情没必要由需求文档来驱动，自己想办法就行了 - - 如果觉得自己设计有点困难，在 TDD 中有一个叫 Spike 的技巧：先不写测试，直接去写实现，用代码来学习/熟悉这个未知领域。熟悉之后把刚写的代码扔掉，回归到严格的 TDD 从头写起。

不知道我猜对了没。

＃7 楼 @5long 请教哪里有关于 Spike 的技巧 的介绍啊

#8 楼 @golden05 我手头没有。用 Google 搜 TDD Spike 试试吧。

#8 楼 @golden05 Spike 其实是一种学习手段。所以有人说 Spike to learn, TDD to build.. 比如你要从 twitter 上抓点东西，你不知道 api 怎么工作，你不知道返回数据是什么样，你有很多未知.. 此时要做 spike 就是写一些简单的代码（不考虑结构，不考虑优美，甚至可以 dirty）来完成这个功能。让你了解整个你要实现的东西到底是怎么工作的。

Spike 的代码是不能进入 production 的。完成 spike 后，你再走 TDD 重新实现这个进入 production 的代码。

测试太重，功能就很难改动，开发人员会有惰性。

Kent Beck 最近说了

I get paid for code that works, not for tests, so my philosophy is to test as little as possible to reach a given level of confidence

http://stackoverflow.com/questions/153234/how-deep-are-your-unit-tests

当然这有很多种理解，不愿写测试的人可能欢呼「测试无用」，我的理解是测试的分量应该能「夹住」易错的地方，但是不要给功能修改带来负担。

在我看来 写测试是需要的.... 至于你是不是一定要 TDD 我觉得看情况的... 按我们的案例来讲 40% 左右是测试先行的.... 其余的是测试后行....

Cucumber 用不用看你的喜好.... 我个人不算喜欢...当然你喜欢要用问题也不大....

TDD 最大的优势还是在 model....我建议从 model 开始入手学习 TDD/BDD...

还有？是否都坚持测试驱动代码开发吗？

写银行系统，是。 写自己博客，不是。

#11 楼 @Rei 没这么简单啊，我想要升级 Rails 版本，我就希望做高代码覆盖率的测试，否则根本难以想象哪个功能会出问题

#1 楼 @5long scenario outline 是测试中运用十分广泛的功能，感觉如果用 Rspec 写就会很难看的说

我们用 https://github.com/jnicklas/turnip

谢谢大家的分享

多用，多看，多读。

#15 楼 @iBachue 我们用的是 Robot Framework，主要问题还是在于开发者不喜欢写（连 QA 都不喜欢 - -），写了也不会有 PM 来看。

面临的问题各有不同吧。

api，构架，命名等有太多未知，可以在完成一个模块代码，并准备开始新的模块开发时，考虑引入测试，不过这个 TDD 更多地是保证新的模块代码不会影响到已经完成的模块

#19 楼 @5long 其实我觉得 文档不是给上面人看的 更不是给机器人看的 而是给将来的新人看的 我当初接手我现在的项目的时候 文档非常匮乏 项目中其他人也是新接手这个项目的 很多功能都完全不知道 做新功能的时候导致以前很多比较隐蔽的功能出了问题 所以我一直觉得在给新功能写测试的时候顺便写下文档是个很好的习惯，防止以后接手的新人犯下同样的错误

Don’t use Cucumber unless you live in the magic kingdom of non-programmers-writing-tests (and send me a bottle of fairy dust if you’re there!)

http://37signals.com/svn/posts/3159-testing-like-the-tsa

我感觉 cucumber 让开发人员来写太啰哩啰唆，曾经用过一段 cucumber，真是煎熬，换回 rspec request+capybara 感觉顺手很多。 如果没人强迫你用 cucumber，就让 rspec 搞定所有测试吧。

谢谢大家的分享，不过我个人还是觉得需求文档和项目建设中的文档非常重要

#21 楼 @iBachue 赞同! 如果没有文档对测试脚本进行描述，新人都不知道是做什么的，或者需要花更多时间搞明白。

我认为最好是有 BA 来写这些 cucumber 的需求，然后开发或者测试来写测试的实现。这样 cucumber 写出来的 spec 方便维护，同时也是链接 BA 和开发沟通的桥梁。

我是测试人员 粗体，从我的角度我看到 cucumber 的好处有以下几点：1 建立起来 DSL 领域语言（适合任何领域），是项目中各种角色的桥梁 2 可以用来做测试用例文档 3 可以用作需求文档 4 项目种各种角色如果来了新人都可以看的学习文档 5 测试引导开发的各种好处都有 6 可以做回归测试

从业了 5,6 年测试，感觉一个项目中每个人对同样一个需求有不同的理解，导致需求实现到最后变了形，如果这个时候再从头改，很多开发就不愿意了。如果在需求的最前面用人类语言写的文档作为前期的沟通，那么前面说的这个风险就会降低

不论开发用什么工具顺手，你做的再快，如果你做出来的东西已经背离了需求的本意，做的快了又有什么意义那？

不要相信人的记忆，久了总会遗忘，还是有个文档最好

cucumber 是给产品经理用的