ruby-on-rails - 在规范中使用 describe/it 优于 feature/scenario 的优势？ (除了语法糖)

Question

Ruby 1.9.3、Rails 3.1.10、RSpec 2.13.0、Capybara 2.2.1

我正在为 Rails 3 应用程序编写测试——一个供客户(和管理员)配置各种电话设置的 GUI。我已经编写了 6 个左右的规范文件，之前还编写了很多其他文件(我将其用作模板)。以下是规范文件的快照。

# spec/features/admin/administrators_spec.rb
require 'spec_helper'
include AdministratorHelper
include Helpers
feature "Exercise Administrators page"
  include_context "shared admin context"
  background do
    visit administrators_path
  end
  scenario "show index page" do
    title.should == "Administrators"
  end
  # ... other happy path tests
  # SAD PATH TESTS #
  scenario "validation: delete no administrators", js:true do
    click_button "Delete"
    page.driver.accept_js_confirms!
    error_message("Error: You did not select any administrators for deletion.")
  end
end

据我了解，feature/scenario 是 Capybara 独有的...和验收测试。其他合作者说我们的“验收测试”测试一切——数据库是否保存条目， View 是否正确呈现等。每个规范都与 GUI 中的页面相关联，而不是模型/ Controller 。

他让我参加了 edX (CS169.1x) 类(class)，他们以不同的方式教授测试——每个模型和 Controller 都有单独的规范文件。他们还使用 describe/context/it 方法编写测试。

1. 使用 describe/it 编写测试相对于 feature/scenario 有什么优势吗？ (除了语法糖)
2. 通过使用 Capybara 的功能/场景，它会减慢测试套件的速度吗？ (与使用 RSpec 的关键字相比)
3. 我正在编写的测试到底是什么(如代码块中所述)？验收、单位、组合？
4. 像上面那样单独编写测试是否可以实现更高的覆盖率？ (我们的下一个目标是 >80%)

感谢您提供的所有帮助和说明。

Answer 1

我觉得这个问题有点宽泛，但可以根据我自己的经验提出一些建议和意见来回答。

1. Is there any advantage to writing tests with describe/it over feature/scenario? (Besides syntactic sugar)

据我所知没有。但是，您可能会发现一些方便的测试框架功能在一种方案中比在另一种方案中更容易实现。

2. By using Capybara's feature/scenario, does it slow down the test suite? (Compared to using RSpec's keywords)

仅使用关键字不会对处理速度产生很大影响。您使用什么样的网络驱动程序和主机模拟将产生更大的影响。

3. What exactly are the tests I am writing (as explained in the code block)? Acceptance, unit, a combination?

我称之为验收测试。然而，并不总是有明确的分界线，您需要查看测试将如何运行，以及它们将如何在您的开发过程中使用。

一个成熟的开发管道可能有两个或三个用于不同目的的独立测试套件，并且可能使用不同的测试框架来实现。例如，您可能需要一组非常快速的测试(通常是单元测试)作为新代码提交的快速自动化测试来运行。

4. Would writing tests like the above alone achieve higher coverage? (Our next goal is >80%)

测试可以使用应用程序的任何用户可访问的功能，并且您自己的任何被使用的代码都可以被视为涵盖。如果您没有大量实用程序脚本或其他用户无法访问的代码，您很可能可以获得高于 80% 的 C0 覆盖率(Ruby 覆盖率工具通常不会提供更深入的细节，例如 C1)。

---

我怀疑使用特定测试框架的关键字会产生最小的影响。但是，使用 Capybara 通过 Web 界面对应用程序进行验收测试要比对单个模块运行较低级别的单元测试要慢得多。

测试速度可以有数量级的变化。对于围绕快速模块的紧密单元测试，我可能期望每秒运行 100 个示例。在 Web 开发项目中，我通常在单元测试中每秒运行 10-20 个示例，但在验收测试中可能每秒运行 1 个示例(这大致是您在这里得到的大概)。当在站点的托管副本上通过浏览器驱动程序使用 Capybara 时，我可能希望在 10 秒内运行一个示例，因此具有 100 多个测试的套件必须仅针对关键路径测试运行，例如与发布候选测试。