在规范中使用describe / it over feature / scenario的优势？ （除了语法糖）

时间：2015-01-02 14:35:07

标签： ruby-on-rails ruby rspec testng acceptance-testing

Ruby 1.9.3，Rails 3.1.10，RSpec 2.13.0，Capybara 2.2.1

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

# 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独有的......以及验收测试。其他合作者说我们的验收测试＆＃34;测试所有内容 - 数据库是否保存了条目，视图是否正确呈现等。每个规范都与GUI中的页面相关联，而不是与模型/控制器相关联。

他让我参加edX课程（CS169.1x），他们教授不同的测试 - 每个模型和控制器单独的spec文件。他们还使用describe / context / it方法编写测试。

  1. 使用describe / it而不是feature / scenario编写测试是否有任何优势？ （除了语法糖）
  2. 使用Capybara的feature / scenario，是否会降低测试套件的速度？ （与使用RSpec的关键词相比）
  3. 我正在编写的测试究竟是什么（如代码块中所述）？接受，单位，组合？
  4. 像上述一样编写测试会获得更高的覆盖率吗？ （我们的下一个目标是> 80％）

    5. 感谢您的帮助和澄清。

1 个答案:

答案 0 :(得分：4)

我认为问题有点广泛，但我可以根据自己的经验回答一些建议和意见。

  
      
  1. 使用describe / it over feature / scenario编写测试是否有任何优势？ （除了语法糖）
    2.   

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

  
      
  1. 通过使用Capybara的功​​能/场景，它是否会降低测试套件的速度？ （与使用RSpec的关键词相比）
    2.   

仅使用关键字不会是处理速度的重要因素。您正在使用哪种Web驱动程序和主机模拟将产生更大的影响。

  
      
  1. 我正在编写的测试究竟是什么（如代码块中所述）？接受，单位，组合？
    2.   

我会称他们为验收测试。但是，并不总是有明确的分界线，您需要了解如何运行测试，以及如何在开发过程中使用它们。

成熟的开发管道可能有两个或三个单独的测试套件，用于不同的目的，可能使用不同的测试框架实现。您可能希望实现一组非常快速的测试（通常是单元测试），以便作为新代码提交的快速自动化测试运行。

  
      
  1. 单独编写上述测试会获得更高的覆盖率吗？ （我们的下一个目标是> 80％）
    2.   

测试可以执行应用程序的任何用户可访问的功能，并且可以考虑覆盖您自己运行的任何代码。如果您没有很多实用程序脚本或其他用户无法访问的代码，那么您可能会获得高于80％的C0覆盖率（Ruby覆盖工具通常不会提供更深入的详细信息，如C1）。

我怀疑使用特定测试框架的关键字影响很小。但是，使用Capybara通过Web界面验证应用程序将比运行单个模块的低级单元测试慢得多。

测试速度可以变化几个数量级。对于快速模块周围的严格单元测试，我可能希望每秒运行100个示例。在一个Web开发项目中，我通常在单元测试中每秒运行10-20个示例，但在验收测试中可能每秒运行1个例子（这大概就是你在这里得到的球场）。当通过浏览器驱动程序在站点的托管副本上使用Capybara时，我可能希望在10秒内运行一个示例，因此必须仅为关键路径测试运行具有100多个测试的套件，例如与候选版本相比。

相关问题
最新问题