Rails：追溯添加测试的良好流程？
我有一些应用程序，我想返回并为其追溯构建测试套件（RSpec 和 Cucumber），但开始该过程有点令人畏惧。
返回现有应用程序并为其构建测试套件的流程是什么？
I've got a few apps that I'd like to go back and retroactively build a test suite (RSpec & Cucumber) for, but it's a little daunting to get that process started.
What would your process be for going back on an existing app and building out a test suite for it?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我会先添加高级测试（黄瓜）。这将使您确信行为不会在不知不觉中发生变化。我不会去添加 rspec 测试（或者可能只是一些重要的测试），因为您可能也想进行很多重构。
然后，运行 metrics。 MetricFu 最近获得了一个名为“HotSpots”的指标，它将结合其他指标并为您指出最大的麻烦点在代码中。这些地方通常对您的应用程序也是最关键的。将它们修复得足够好，以便可读并且您可以很好地了解它的内容。暂时不要太过分。
然后，对于您要添加的每个新功能，添加规格并清理您正在交互的一些代码。因此，测试和重构新功能的依赖关系，但不要超出范围。分小块地做，否则你很快就会失去希望。
I would go and add highlevel tests (cucumber) first. This will give you the confidence that the behavior won't change unnoticed. I wouldn't go and add rspec tests (or maybe just a few imporant ones) because you'll probably want to refactor a lot too.
Then, run metrics. MetricFu recently got a metric called "HotSpots", that will combine other metrics and point you to the biggest troublespots in the code. These places are usually also the most critical to your application. Fix them just enough so there readable and you get a good sense of what it's about. Don't go overboard just yet.
Then, for every new feature that you'll add, add specs and clean up some code that you're interacting with. So test and refactor the dependencies of new features, but don't go beyond that. Do it in tiny chunks or you'll lose hope quickly.
我最近开始自己解决向一堆旧代码添加测试的问题，我发现非常有帮助的是 rcov （我不关心 rcov Rails 插件，只需 cd 来测试并运行一个小 shell 脚本，该脚本运行带有正确排除的 rcov 并在测试全部通过时打开报告。）然后，我开始处理最接近的那些100% 覆盖率，只是一点一点地计算百分比。与“呃，我从哪里开始为此添加测试？！”相比，这是更可衡量的进展。
I recently started tackling adding tests to a bunch of old code myself, and what I found immensely helpful is rcov (I don't bother with the rcov rails plugin and just cd to test and run a little shell script that runs rcov with the right exclusions and opens the report if the tests all pass.) Then, I started tackling the ones that were closest to 100% coverage and just working up the percentages bit by bit. It's much more measurable progress than, "Ugh, where do I start with adding tests for this?!"
我最近为客户项目做了很多这样的事情。对我来说最大的障碍似乎是带有或不带有 RJS 的内联 javascript 的猖獗使用。 [旁注：执行 AJAX 的方法有正确和错误之分，大多数人都做错了™。] 我通常大量使用 Cucumber 和一些 rspec 来进行奇怪的单元测试。
要考虑的变量多种多样，但一个好的起点是为模型进行一些单元测试。创建一些工厂并测试您的验证，以及您认为需要测试的任何自定义行为。
如果您不感兴趣或者您已经有了一套单元测试并且想要添加集成，那么下一个问题是您执行大量内联 javascript 或 RJS 的程度。如果你的应用程序非常“ajaxy”，你需要从黄瓜的硒驱动程序开始，它像二月的糖蜜一样慢，但它可以完成工作。一旦您获得了涵盖应用程序的全部功能（甚至只是重要内容）的一套测试，我就会开始重构 JavaScript 以使其不引人注目地运行。
您可以采取的另一个方向是为您的控制器和视图构建额外的 rspec，但我不太喜欢这种模式，因为您正在测试实现而不是功能< /em>。
需要记住的重要一点是，这一切不必在一夜之间发生。分析您的工作流程（例如登录、执行任务 A、执行任务 B 等）并确定哪些工作流程涵盖了 80% 的典型用例。首先测试这些。然后使用 metric_fu 或简单的 rcov（或任何其他覆盖工具）之类的东西，并找到逻辑密集且未经测试的代码区域。我喜欢 metric_fu ，因为它运行的工具套件可以为您提供这两条信息。
I've been doing a lot of this lately for client projects. The biggest blocks for me seem to be the rampant use of inline javascript with or without RJS. [Side note: there's a right and a wrong way to do AJAX, and most people are Doing It Wrong™.] I typically use cucumber heavily with a bit of rspec for strange unit tests.
The variables to consider are diverse, but a good place to start is with a few unit tests for your models. Create some factories and test your validations, along with any customized behavior you think needs testing.
If you're not into that or you've already got a suite of unit tests and you want to add integration, the next question is the extent to which you're doing a lot of inline javascript or RJS. If your app is very "ajaxy" you'll need to start with the selenium driver for cucumber, which is slow as molasses in february, but it'll get the job done. Once you've got a suite of tests covering the full functionality (or even just the important stuff) for your application, I'd begin refactoring the javascript to function unobtrusively.
Another direction you could go would be to build additional rspecs for your controllers and views, but I don't really like this pattern as you're getting into testing the implementation instead of the functionality.
The important thing to remember is that it doesn't all have to happen overnight. Analyze your workflows (e.g. logging in, doing task A, doing task B, etc) and determine which ones cover 80% of your typical use cases. Test those first. Then use something like metric_fu or just plain rcov (or any other coverage tool) and find areas of your code that are logic-dense and untested. I like metric_fu for this because the suite of tools it runs can give you both of those pieces of information.
我在这里有点偏离主题，但无论如何......
我认为 Rails 中模型的单元测试（至少 3 个）是毫无价值的......我的意思是特别是在编写代码时，所以你没有做 TDD 。您想测试您的验证吗？为什么 ？只要阅读代码，您就会自己找出错误。我说 Rails（在某些地方）提供了如此人性化的语法，以至于对它进行单元测试将是一种耻辱。
在我看来，这样的语法本身就是一种规范。那么，为什么要笔试呢？
需要澄清的是：不，我并不是说测试一直都是无用的。我不是在某个随机的网络机构工作...:p
I'm a little off topic here, but anyway ...
I think unit testing of models in rails (3 at least) is kind of worthless... I mean especially when the code is written, so you're not doing TDD. You want to test your validation ? Why ? Just read the code and you'll figure out errors by yourself. I say that rails provides (in some place) such a human syntax that it would be a shame to unit test it.
In my opinion, such a syntax is itself a specification. Then, why writting test ?
And just to be clear : No, I'm not saying testing is useless all the time. I'm not working in some random web agency ... :p