0

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

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

4

4 回答 4

2

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

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

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

于 2013-10-05T04:20:31.447 回答
2

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

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

如果您是 Rails 新手，您可以在这篇 37signals 博客文章中了解其固执己见的创建者对测试的看法。小经验法则，但也许可以将您推向该主题的新方向。

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

于 2013-10-05T05:12:34.620 回答
1

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

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

于 2013-10-05T04:47:51.647 回答
1

一些东西：

别

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

做

对于模型：

  • 测试验证
  • 测试自定义逻辑

对于控制器：

  • 测试非平凡路线
  • 测试重定向
  • 测试认证
  • 测试实例变量赋值

对于视图：

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

Rails 指南中的更多内容

于 2013-10-05T12:58:34.367 回答