Rails：追溯添加测试的好过程？答案

【问题标题】：Rails: Good process for adding tests retroactively?Rails：追溯添加测试的好过程？
【发布时间】：2010-12-13 15:04:45
【问题描述】：

我有一些应用程序我想返回并追溯构建一个测试套件（RSpec 和 Cucumber），但启动该过程有点令人生畏。

您将如何返回现有应用并为其构建测试套件？

【问题讨论】：

+1 因为我问自己同样的问题

标签： ruby-on-rails testing rspec cucumber

【解决方案1】：

我会先添加高级测试（黄瓜）。这将使您确信行为不会被忽视。我不会去添加 rspec 测试（或者可能只是一些重要的测试），因为你可能也想重构很多。

然后，运行metrics。 MetricFu 最近获得了一个名为“HotSpots”的指标，它将结合其他指标并指出代码中最大的问题。这些地方通常也是您的应用程序最关键的地方。将它们修复到足够可读的程度，并且您可以很好地了解它的含义。暂时不要太过分。

然后，对于您要添加的每个新功能，添加规范并清理您正在与之交互的一些代码。因此，测试和重构新功能的依赖关系，但不要超出此范围。分小块做，否则你很快就会失去希望。

【讨论】：

【解决方案2】：

我最近开始自己处理向一堆旧代码添加测试，我发现非常有帮助的是rcov（我不关心 rcov rails 插件，只需 cd 来测试和运行一个小 shell 脚本使用正确的排除项运行 rcov 并在测试全部通过时打开报告。）然后，我开始处理最接近 100% 覆盖率的问题，并一点一点地计算百分比。这比“呃，我从哪里开始为此添加测试？！”更可衡量的进展

【讨论】：

很好的建议，真的很有帮助！

【解决方案3】：

我最近为客户项目做了很多这样的事情。对我来说最大的障碍似乎是在有或没有 RJS 的情况下大量使用内联 javascript。 [旁注：做 AJAX 有对错之分，大多数人都在做错事™。]我通常大量使用黄瓜和一些 rspec 进行奇怪的单元测试。

要考虑的变量多种多样，但最好从对模型进行一些单元测试开始。创建一些工厂并测试您的验证，以及您认为需要测试的任何自定义行为。

如果您对此不感兴趣，或者您已经拥有一套单元测试并且您想要添加集成，那么下一个问题是您在多大程度上执行了大量内联 javascript 或 RJS。如果你的应用程序非常“ajaxy”，你需要从黄瓜的 selenium 驱动程序开始，它在 2 月就像糖蜜一样慢，但它会完成工作。一旦你有一套测试涵盖了你的应用程序的全部功能（甚至只是重要的东西），我会开始重构 javascript 以不显眼地运行。

您可以采取的另一个方向是为您的控制器和视图构建额外的 rspec，但我不太喜欢这种模式，因为您正在测试实现而不是功能。

要记住的重要一点是，这一切都不必在一夜之间发生。分析您的工作流程（例如登录、执行任务 A、执行任务 B 等）并确定哪些工作流程涵盖了 80% 的典型用例。先测试那些。然后使用 metric_fu 之类的东西或只是普通的 rcov（或任何其他覆盖工具），并找到逻辑密集且未经测试的代码区域。我喜欢 metric_fu 因为它运行的工具套件可以为您提供这两种信息。

【讨论】：

【解决方案4】：

我在这里有点跑题了，但无论如何......

我认为在 Rails 中对模型进行单元测试（至少 3 个）有点毫无价值……我的意思是特别是在编写代码时，所以你没有做 TDD。你想测试你的验证吗？为什么？只需阅读代码，您就会自己找出错误。我说 Rails （在某些地方）提供了这样一种人类语法，以至于对它进行单元测试是一种耻辱。

在我看来，这样的语法本身就是一种规范。那么，为什么要写测试呢？

并且要明确一点：不，我并不是说测试一直都是无用的。我不在一些随机的网络机构工作......：p

【讨论】：

我理解你的观点。不过，如果您不确定，请添加规格。如果它是您的应用程序的行为，您应该对其进行测试。模型是业务逻辑的主要部分，所以我认为大多数单元测试/规范都是针对模型的。
确实如此。总结一下我的观点：如果你的语言语法看起来像商业可读的，那么为什么要测试呢？
防止回归，您编写的额外代码会破坏旧功能。除非您计划每次进行更改时都重新阅读您的代码...
没错，加雷斯！这就是我为旧代码编写测试的原因。在任何类型的重要范围的应用程序中，对代码的一个区域进行更改可能会影响完全独立的代码部分中的内容。更改该控制器方法可能会破坏单元测试。更改模型逻辑，可能会破坏控制器。在过去的几个月里，这已经救了我的培根很多次了。
@Gareth ;精确的。规范不同于自动化测试:)