在 Ruby on Rails 中什么值得测试？ [关闭]答案

【问题标题】：What's worth testing in Ruby on Rails? [closed]在 Ruby on Rails 中什么值得测试？ [关闭]
【发布时间】：2013-10-05 04:00:16
【问题描述】：

我在 Ruby on Rails 上做一份合同工作，这主要是因为编写测试而导致生产力的灾难。这是我第一次在实践中使用 TDD，它并不顺利，因为我花了很多时间编写测试，几乎没有任何结果可以显示。我在想，也许我试图通过为每个模型和控制器中的每个功能编写测试来进行过多的测试。

如果我无法实现 100% 的测试覆盖率，我可以使用哪些标准来确定“此功能是否值得测试”？例如，集成测试会胜过单元测试吗？

【问题讨论】：

标签： ruby-on-rails ruby unit-testing rspec

【解决方案1】：

如果您刚刚开始在 ruby 或 Rails 世界中进行测试，我会提出以下建议：

从 rspec 开始。对于以前从未使用过它的单个开发人员来说，使用像 Cucumber 这样的工具进行自动化验收/集成测试可能会耗费大量时间。这些工具的成功通常取决于 A) 非常具体的高质量 UI 规范，B) 可以使用无头浏览器模拟器轻松测试的 UI 约定以及 C) 提前熟悉这些工具。
测试单个方法。测试它们是否返回您期望的值。测试当您向他们提供不良数据时，他们会以适当的方式做出响应。当你意识到它们时测试任何边缘情况。
要非常小心，在测试中正确地进行存根和模拟。编写一个 30 分钟的测试很容易，却发现你并没有真正测试你需要测试的东西。
不要对你的 TDD 进行微观管理——有些人会告诉你测试编写方法的每一个微小步骤：首先测试模型是否有一个名为“foo”的方法，然后测试它是否返回非nil，然后测试它是否返回一个字符串，然后测试该字符串是否包含某个子字符串。虽然这种方法在您实现复杂的东西时会很有帮助，但它也可能会浪费时间。只需跳过前两个步骤。话虽如此，很容易在另一个方向上走得太远，在开始实施之前通过复杂的测试指定方法的行为，然后开始实施却发现你搞砸了测试。
不要编写只是说“这是我编写该功能的方式，不要更改它”的测试。测试应该反映方法的基本业务逻辑。如果您专门编写测试，以便在其他开发人员更改您的实现的某些非关键部分时测试会失败，那么您就是在浪费时间并添加多余的代码行。

这些只是我在类似情况下的一些观察。祝你好运，测试会很有趣！不完全是。我是认真的。

【讨论】：

【解决方案2】：

100% 的测试覆盖率是一种幻想和浪费时间。你的测试应该有一个目的，通常是为了让你相信你编写的代码是有效的。不是绝对的信心，而是一定程度的信心。 TDD 应该是一种工具，而不是一种限制。

如果这不能让你的作品变得更好，你为什么要这样做？更重要的是，如果您未能生成有用的代码并失去合同，这些测试毕竟不是太有用？这是一种平衡，听起来你站在了错误的一边。

如果您是 Rails 新手，您可以了解其固执己见的创建者对测试 in this 37signals blog article on the topic 的看法。小经验法则，但也许可以将您推向该主题的新方向。

还有关于改进 RSpec 使用的很好的参考资料，例如 betterspecs.org、The RSpec Book 和 Everyday Rails Testing with RSpec。使用不当可能会导致维护规范令人头疼。

【讨论】：

DHH 的博文是促使我提出这个问题的原因之一。很多开发人员告诉我，TDD 应该与您的编码实践交织在一起，但对我来说，这会导致 100% 的测试覆盖率并减慢您的开发速度。我认识的大多数开发人员 - 尽管他们提倡测试 - 许多人根本不会自己做。

【解决方案3】：

我的建议是尝试让您的测试和代码编写尽可能紧密耦合，并结合项目的敏捷方法。

通过这种方式，您将不断有新的东西向客户展示，因为测试刚刚开始。我看到的最大错误是，对于刚接触测试的团队来说，最大的错误是继续将测试视为一项单独的活动。最重要的是，我继续看到开发人员说一个功能已经完成......但需要在“某些点”进行一些重构和一些更好的测试。 “某个点”很少出现。但有一件事是不可避免的 - 至少在几个月内它会在短期内慢得多，但质量要好得多，而且你会避免构建“big ball of mud”，我似乎在这么多更大的机构。

【讨论】：

如何将 TDD 和敏捷结合起来？...在我看来，因为敏捷是关于处理不断变化的需求，所以这种哲学的问题之一是需求的变化会导致双重工作更改代码和测试。
我合作过的许多组织都发现这很有帮助。敏捷有助于推动满足用户要求的软件，而 tdd 有助于推动其技术细节组件

【解决方案4】：

一些事情：

不要

测试数据库
测试 ActiveRecord 或您正在使用的任何 ORM

做

对于模型：

测试验证
测试自定义逻辑

对于控制器：

测试非平凡路线
测试重定向
测试身份验证
测试实例变量赋值

对于视图：

我还没有开始测试视图，但我遇到了我希望这样做的情况。例如测试表单中的字段。

更多信息请访问Rails Guides

【讨论】：

当您说“测试验证”时，您是指自定义验证吗？总的来说，我总是试图提醒自己不要测试 Rails 的代码。这包括开箱即用的验证。现在自定义验证完全是另一回事了。
@Charles 我同意不测试 Rails 代码。但是，我确实在我的规范中包含了 validates_presence_of 等验证，因为它们描述了需要哪些模型属性，应该是唯一的，等等。