DHH对unit testing：RSpec确实是不必要的复杂吗？
我碰巧是Ruby Inside的订阅者，因为我对Rails特别感兴趣。 昨天，Rails的创建者David Heinemeier Hansson几乎说他只是使用测试/单元。 我会理解，因为它是Rails内部，但他似乎给出了强烈的意见。 他认为RSpec和Cucumber是不必要的复杂。
我通常不会太注意，但这取决于谁说了什么。 我很尊重汉森，他的意见让我思考。 当我开始使用Rails时，我从未真正研究过测试/单元。 只是RSpec和黄瓜。
这就是我想要你的洞察力的原因。 您认为RSpec确实很复杂吗？ 写测试/单元花费的时间和精力更少吗？
我的建议是使用Shoulda（扩展Test :: Unit）或RSpec和Capybara，以及-no- Cucumber。
我认为在嵌套上下文中使用RSpec或Shoulda绝对值得做。 RSpec肯定是重量级的（也许是超重的），因为这个原因，我正在努力。
黄瓜，我终于明白了，比通常值得的更麻烦。 通过简单的集成测试和Capybara，您可以更简单，更健壮地完成您的需求。 记住 – Capybara！= Cucumber，而Capybara本身就很有能力。
Shoulda很好，因为它只是增加了标准Test :: Unit框架的便利性，因此比RSpec轻得多（从技术上讲，每个都解决了一组不同的问题，但它们都提供了嵌套上下文function）。 RSpec的优点是可以更自然地读取断言，并且在许多情况下还可以生成更有用的失败消息，而无需在断言上编写消息参数。
另外，请记住，Cucumber实际上并不需要RSpec，所以如果你想继续使用Cucumber，你可以只用Test :: Unit来做。 选择比比皆是。
这都是关于语义的。 RSpec和Test :: Unitfunction相似。 就个人而言，我一直更喜欢RSpec，因为我发现使用它编写测试更自然。 我也喜欢编写自定义匹配器的简单性，并且提供的默认匹配器非常有用。
黄瓜完全是一种不同的野兽。 是的，如果你没有正确组织你的步骤定义，它会相当麻烦并且变得难以维护，但它确实有一个非常强大的用例，那就是当你的客户编写你的规范时。
我参与了客户与我们的QA团队一起编写Cucumber场景的项目。 作为非技术人员，在代码中指定用户故事是一种非常平易近人且自然的方式。 黄瓜真的帮助我们走完了跟随我们敏捷实践的步伐。 最终产品的质量受益于此但不，我不喜欢 Cucumber作为开发人员:)
这是个人品味的问题。
我喜欢写简单的黄瓜测试而不用担心细节问题。 只是测试我的应用程序的“快乐”路径。 （便携，易懂，慢）
我将细节留给了测试/单元。 （简单，快速）
需要更多时间来理解：
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。
我不喜欢function测试，因为在重构之后，id可能会消失，会话期望可能会改变。 如果是这种情况，您将需要重构您的代码和测试。 如果你使用黄瓜，你就不必改变你的情景了。