Ruby on Rails 中的全栈测试选项

发布于 2024-09-25 22:17:03 字数 506 浏览 2 评论 0原文

Rails 应用程序的全栈测试有很多选项。有些使用真正的浏览器,有些是无头的,有些根本不运行 javascript。

您使用或推荐哪些工具,为什么?

浏览器模拟器或自动化程序列表

  • Rails 对集成和功能测试的内置支持(无 JS)
  • Webrat
  • Webrat::selenium
  • Selenium
  • Celerity(通过 Culerity)
  • Watir
  • ...

测试 DSL 和框架列表:

  • Rails 默认值(断言,...)
  • Shoulda
  • Cucumber
  • Capybara(多个浏览器模拟器的统一 DSL)
  • ...

There are quite a number of options for Full-Stack testing of Rails applications. Some use real browsers, some are headless, some don't run javascript at all.

Which tools do you use or recommend and why?

List of browser simulators or automators:

  • Rails built-in support for integration and functional tests (no JS)
  • Webrat
  • Webrat::selenium
  • Selenium
  • Celerity (through Culerity)
  • Watir
  • ...

List of testing DSLs and frameworks:

  • Rails defaults (assertions, ...)
  • Shoulda
  • Cucumber
  • Capybara (unified DSL for several browser simulators)
  • ...

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

浅忆流年 2024-10-02 22:17:03

所有 Rails 应用程序都受益于单元和功能测试的良好覆盖,无论您使用 rspec 还是 Shoulda 等,这主要取决于个人喜好。我是 shoulda 的粉丝,主要是因为它提供的上下文块,使设置测试场景变得更容易、更清晰易懂。

我认为不需要浏览器模拟器/自动化程序,除非您的应用程序的 javascript 非常繁重。我建议只使用它们来测试 JavaScript,为此目的,驾驶真实的浏览器肯定比模拟更好。我现在正在开发的应用程序需要大量 JavaScript,我们使用 cucumber 以及 watir/firewatir 来运行我们的 Cucumber 测试firefox 用于我们网站上的 javascript 驱动功能。

All rails applications benefit from a good coverage of unit and functional tests, whether you use rspec or shoulda etc, is mostly a matter of personal preference. I'm a fan of shoulda mostly for the context blocks it provides, making setting up test scenarios much easier and clearer to understand.

I don't think browser simulators/automators are needed unless your application is quite javascript heavy. I'd recommend only using them to test javascript, and for that purpose it's definitely better to go with driving a real browser than to simulate. The app I'm working on now is quite javascript heavy and we're using cucumber along with watir/firewatir to run our cucumber tests in firefox for the javascript driven functions on our site.

风轻花落早 2024-10-02 22:17:03

在过去的几年里,我在 Rails 职业生涯中使用了很多东西。

目前正在 JRuby 上开发一个相当大的 Rails 应用程序,具有非常可靠的测试覆盖率,我们的堆栈如下所示。

单元测试:

  • RSpec 覆盖模型、助手、库和控制器。 控制器覆盖率往往是非常高级的
  • 对于使用一些非常前沿的 JS 和 HTML 5 魔法的项目来说,

JSpec 覆盖率功能测试:

  • 使用 Capybara 和 Culerity 的 Cucumber(我们刚刚从 WebRat 转换以获得 JS 重前端的覆盖率) -从 Cucumber 结束)
  • Selenium 现在是“遗产”并慢慢迁移到 Cucumber/capybara

I have used a bunch of things during my Rails career over the last few years.

Currently working on a pretty large Rails app on JRuby with very solid test coverage and our stack looks like the following.

Unit Testing:

  • RSpec coverage of models, helpers, libraries and controllers. Controller coverage tends to be very high-level
  • JSpec coverage for a project that is using some pretty cutting edge JS and HTML 5 wizardry

Functional Testing:

  • Cucumber using Capybara and Culerity (we just converted from WebRat in order to get coverage of JS-heavy front-ends from Cucumber)
  • Selenium that is now "legacy" and slowly being migrated to cucumber/capybara
浴红衣 2024-10-02 22:17:03

在我目前正在进行的项目中,为了测试完整的堆栈,我们使用 Cucumber 和水豚作为驱动程序。

前端的 javascript 非常繁重,我尝试了几个无头浏览器驱动程序(capybara-envjs 和 akephalos),但两者都错误地失败了在真实浏览器中通过的测试。

In the project I'm currently working on, for testing the full stack we're using Cucumber with capybara as the driver.

The front end is very javascript heavy, I've tried a couple of headless browser drivers (capybara-envjs and akephalos), but both were incorrectly failing tests that passed in a real browser.

謸气贵蔟 2024-10-02 22:17:03

我使用 Cucumber + Capybara 以及 selenium-webdriver 和rack-test 驱动程序的组合。 Capybara 很好地抽象了由 selenium-webdriver 驱动的浏览器内测试之间的差异,这些测试实际上可以测试 JavaScript 在浏览器中的工作情况,但需要一段时间才能运行并测试仅针对由 selenium-webdriver 生成的 HTML 运行的测试控制器/动作,运行速度更快,但不测试 JavaScript。这意味着相同的场景和步骤定义集可以在浏览器中运行,也可以不在浏览器中运行,而无需维护重复的步骤定义集。

I'm using Cucumber + Capybara with a combination of selenium-webdriver and the rack-test driver. Capybara does a good job of abstracting the difference between in-browser tests that get driven by selenium-webdriver for test that can actually test that the JavaScript works in a browser but take a while to run and test that just run against the HTML produced by the controller/action, which run much faster but don't test JavaScript. This means that the same set of scenarios and step definitions can be run in a browser or not without having to maintain duplicate sets of step definitions.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文