如何在RSpec中为不同用户上下文编写DRY风格的请求测试用例？

1. 用RSpec共享示例抽离重复逻辑 #

把CRUD的测试模板抽成共享示例，不同用户角色只需要传入对应的预期响应状态，就能复用整套测试逻辑，不用重复写每个接口的测试代码。

示例代码：

# 定义共享示例，放在spec/support/shared_examples/widget_crud_spec.rb
RSpec.shared_examples "Widget CRUD权限验证" do |user_role, expected_statuses|
  let(:user) { create(user_role) } # 假设用FactoryBot创建用户实例
  let(:widget) { create(:widget) }

  before { sign_in user } # 假设用Devise做身份验证

  it "处理列表接口GET /widgets" do
    get "/widgets"
    expect(response).to have_http_status(expected_statuses[:index])
  end

  it "处理详情接口GET /widgets/:id" do
    get "/widgets/#{widget.id}"
    expect(response).to have_http_status(expected_statuses[:show])
  end

  it "处理创建接口POST /widgets" do
    post "/widgets", params: { widget: { name: "测试组件" } }
    expect(response).to have_http_status(expected_statuses[:create])
  end

  it "处理更新接口PATCH /widgets/:id" do
    patch "/widgets/#{widget.id}", params: { widget: { name: "更新后组件" } }
    expect(response).to have_http_status(expected_statuses[:update])
  end

  it "处理删除接口DELETE /widgets/:id" do
    delete "/widgets/#{widget.id}"
    expect(response).to have_http_status(expected_statuses[:destroy])
  end
end

# 在request spec里调用共享示例
RSpec.describe "Widgets API", type: :request do
  context "管理员身份" do
    include_examples "Widget CRUD权限验证", :admin, {
      index: :ok,
      show: :ok,
      create: :created,
      update: :ok,
      destroy: :no_content
    }
  end

  context "普通用户身份" do
    include_examples "Widget CRUD权限验证", :user, {
      index: :forbidden,
      show: :forbidden,
      create: :forbidden,
      update: :forbidden,
      destroy: :forbidden
    }
  end
end

这样维护时只需要修改共享示例里的逻辑，所有角色的测试都会同步更新，可读性和维护性直接拉满。

2. 参数化测试压缩测试代码 #

用RSpec的参数化特性（可以借助rspec-parameterized gem），把用户角色和对应的预期状态做成参数表，一次定义测试逻辑，自动遍历所有角色执行。

示例代码：

# 先在Gemfile添加gem 'rspec-parameterized'，然后bundle install
RSpec.describe "Widgets API", type: :request do
  using RSpec::Parameterized::TableSyntax

  # 定义参数表：角色 + 各接口预期状态
  where(:user_role, :index_status, :show_status, :create_status, :update_status, :destroy_status) do
    :admin | :ok         | :ok         | :created    | :ok         | :no_content
    :user  | :forbidden  | :forbidden  | :forbidden  | :forbidden  | :forbidden
  end

  with_them do
    let(:user) { create(user_role) }
    let(:widget) { create(:widget) }

    before { sign_in user }

    it "访问列表接口返回对应状态" do
      get "/widgets"
      expect(response).to have_http_status(index_status)
    end

    it "访问详情接口返回对应状态" do
      get "/widgets/#{widget.id}"
      expect(response).to have_http_status(show_status)
    end

    # 其他CRUD接口测试同理
  end
end

这种方式的好处是能直观看到不同角色的权限差异，代码结构非常紧凑，不用重复写多个context块。

3. 封装自定义测试助手 #

把重复的登录、请求断言逻辑做成助手方法，让测试代码专注于权限验证，而非请求细节。

示例代码：

# 在spec/support/request_helpers.rb定义助手
module RequestHelpers
  def sign_in_as(role)
    user = create(role)
    sign_in user # Devise的登录方法
    user
  end

  def test_api_endpoint(method, path, params: {}, expected_status)
    send(method, path, params: params)
    expect(response).to have_http_status(expected_status)
  end
end

# 在request spec里引入并使用
RSpec.describe "Widgets API", type: :request do
  include RequestHelpers

  context "管理员身份" do
    before { sign_in_as(:admin) }
    let(:widget) { create(:widget) }

    it "拥有所有CRUD权限" do
      test_api_endpoint(:get, "/widgets", expected_status: :ok)
      test_api_endpoint(:get, "/widgets/#{widget.id}", expected_status: :ok)
      test_api_endpoint(:post, "/widgets", params: { widget: { name: "新组件" } }, expected_status: :created)
      test_api_endpoint(:patch, "/widgets/#{widget.id}", params: { widget: { name: "更新组件" } }, expected_status: :ok)
      test_api_endpoint(:delete, "/widgets/#{widget.id}", expected_status: :no_content)
    end
  end

  context "普通用户身份" do
    before { sign_in_as(:user) }
    let(:widget) { create(:widget) }

    it "无任何CRUD权限" do
      test_api_endpoint(:get, "/widgets", expected_status: :forbidden)
      test_api_endpoint(:get, "/widgets/#{widget.id}", expected_status: :forbidden)
      # 其他接口同理
    end
  end
end

助手方法把请求和断言的重复逻辑封装起来，让测试代码更简洁，也方便后续扩展其他接口的测试。

4. 下沉权限测试到策略对象 #

如果你的权限逻辑是用Pundit、CanCanCan这类策略对象实现的，优先单独测试策略对象，再在request specs里只验证控制器是否正确应用策略，不用全量测试CRUD。

示例代码：

# 先测试WidgetPolicy（Pundit示例）
RSpec.describe WidgetPolicy do
  subject { described_class.new(user, widget) }
  let(:widget) { create(:widget) }

  context "管理员身份" do
    let(:user) { create(:admin) }
    it { is_expected.to permit_actions([:index, :show, :create, :update, :destroy]) }
  end

  context "普通用户身份" do
    let(:user) { create(:user) }
    it { is_expected.to forbid_actions([:index, :show, :create, :update, :destroy]) }
  end
end

# 然后在request spec里只测试关键路径
RSpec.describe "Widgets API", type: :request do
  context "管理员身份" do
    let(:user) { create(:admin) }
    before { sign_in user }

    it "可以创建组件" do
      post "/widgets", params: { widget: { name: "测试组件" } }
      expect(response).to have_http_status(:created)
    end
  end

  context "普通用户身份" do
    let(:user) { create(:user) }
    before { sign_in user }

    it "无法创建组件" do
      post "/widgets", params: { widget: { name: "测试组件" } }
      expect(response).to have_http_status(:forbidden)
    end
  end
end

这种方式把权限逻辑的测试和接口测试解耦，减少request specs的重复代码，同时让测试关注点更清晰——策略对象测权限规则，request spec测规则是否被正确应用。

内容的提问来源于stack exchange，提问作者Romuloux