DHH 关于单元测试：RSpec 确实不必要地复杂吗？

Question

我碰巧是 Ruby Inside 的订阅者，因为我对 Rails 特别感兴趣。昨天，Rails 的创建者 David Heinemeier Hansson 几乎说他只是使用测试/单元。我会理解，因为这是 Rails 内部的，但他似乎给出了强烈的意见。他认为 RSpec 和 Cucumber 过于复杂。

我通常不会太在意，但这取决于谁说了什么。我非常尊重汉森，他的观点让我思考。当我开始使用 Rails 时，我从未真正研究过测试/单元。只有 RSpec 和 Cucumber。

这就是为什么我需要你的见解。你是否认为RSpec确实很复杂，没有太多附加值？编写测试/单元是否需要更少的时间和精力？

Answer 1

我的建议是使用 Shoulda（扩展 Test::Unit）或 RSpec 与 Capybara，而不是 Cucumber。

我认为对嵌套上下文使用 RSpec 或 Shoulda 绝对值得这样做。不过，RSpec 绝对是重量级的（也许是超重的），因此我对它持观望态度。

我终于明白了，黄瓜比它通常的价值要麻烦得多。您可以通过简单的集成测试和 Capybara 更简单、更稳健地完成您需要的任务。请记住——水豚！=黄瓜，而水豚本身就非常有能力。

Shoulda 很好，因为它只是为标准 Test::Unit 框架添加了便利，因此比 RSpec 轻量得多（从技术上讲，每个框架都解决一组不同的问题，但它们都提供嵌套上下文功能）。 RSpec 的优点是使断言读取起来更自然，并且在许多情况下还可以生成更有用的失败消息，而无需在断言上编写消息参数。

另外，请记住，Cucumber 实际上并不需要 RSpec，因此如果您想继续使用 Cucumber，只需使用 Test::Unit 即可。选择比比皆是。

Answer 2

这都是关于语义的。 RSpec 和 Test::Unit 在功能上类似。就我个人而言，我一直更喜欢 RSpec，因为我发现使用它编写测试更自然。我还喜欢编写自定义匹配器的简单性，并且提供的默认匹配器很有用。

黄瓜是一种完全不同的野兽。是的，如果您没有正确组织步骤定义，它相当麻烦并且变得难以维护，但它确实有一个非常强大的用例，那就是当您的客户编写规范时。

我曾参与过客户与我们的 QA 团队之一一起编写 Cucumber 场景的项目。作为非技术人员，在代码中指定用户故事是一种极其平易近人且自然的方式。在遵循敏捷实践方面，Cucumber 确实帮助我们做到了这一点。最终产品的质量受益于此，但我不喜欢 Cucumber 作为开发人员:)

Answer 3

这是个人品味的问题。

我喜欢编写简单的黄瓜测试而不用担心细节。只是测试我的应用程序的“快乐”路径。 （便携、易于理解、缓慢）

我将细节留给测试/单元。 （简单，快速）

需要更多时间来理解：

get :products, :session => @session_id_for_product_banana
assert_select "table" do
  assert_select "td#name", "Banana"
end

而不是

When I go to the banana page
Then I should see "Banana"

确定这些测试不相等，但谁在乎“Banana”是否在 div 或表格中，或者没有正确的 html-id。

我不喜欢功能测试，因为重构后，id 可能会消失，会话期望可能会改变。如果是这种情况，您将需要重构代码和测试。如果您使用黄瓜，则不必更改您的场景。