使用 RSPEC 进行测试时，如何重用 FactorBot 工厂来构建请求属性？

你真的在很多方面都错过了这个目标。

你真正想要的更像是：

RSpec.describe "Playgrounds", type: :request do
  # this should be done in your test setup
  include FactoryBot::Syntax::Methods 


  # This should be handled with a trait
  let(:user) { create(:user, is_admin: true) }
  let(:playground) { FactoryBot.create(:playground) }

  before do
    # get "/users/sign_in" - don't think you actually need this
    login_as user, scope: :user
  end 

  # Describe the route and not the controller
  describe "GET /playgrounds" do
    let!(:playgrounds) { create_list(:playground, 3) }
    # Don't do that wonky numbering stuff - you don't need it 
    # and it will just confuse you when the examples run in random order
    it "renders a successful response" do
      get playgrounds_url
      # this is ok as a litmus test but doesn't tell you if the controller
      # is actually providing a meaningful response
      expect(response).to be_successful
    end
    # @todo write a test that it actually responds with the playgrounds
  end

  describe "GET /playgrounds/:id" do
    it "renders a successful response" do
      get playground_url(playground)
      # this is ok as a litmus test but doesn't tell you if the controller
      # is actually providing a meaningful response
      expect(response).to be_successful
    end
    # @todo write a test that it actually responds with the playground
  end

  describe "POST /playgrounds" do
    context "with valid attributes" do
      # Use per context let instead 
      let(:attributes) { attributes_for(:playground) }
      it "creates a playground" do
        expect {
          post '/playgrounds', params: {
            playground: attributes
          }
        }.to change(Playground, :count).by(1)
        expect(response).to be_successful
      end
    end 

    context "with invalid attributes" do
      # Use per context let instead 
      let(:attributes) do 
        # I would just define this manually
        {
          foo: ""
        }
      end
      it "doesn't create a playground" do
        expect {
          post '/playgrounds', params: {
            playground: attributes
          }
        }.to_not change(Playground, :count)
        expect(response).to have_http_status :unprocessable_entity
      end
    end 
  end
end

FactoryBot.create并且应该用于填充数据库作为测试设置。您不应该使用它来尝试创建无效记录，因为这会引发错误并且没有意义。索引和显示功能的规范实际上应该只依赖于测试设置来创建前提条件。create_list

如果要在测试创建/更新操作时重用工厂定义，请使用 获取属性的哈希值或仅获取模型的未保存实例。FactoryBot.attributes_forFactoryBot.build

在这里重用工厂听起来是避免 DRY 的好主意。是吗？

如果您订阅 DRY 方法，那么这不是您想要避免的事情。但是，是的，使用工厂可以避免重复，但它们也会降低规范的可读性，因为您必须查看工厂定义才能确切地看到传递的内容。

如何在请求上下文中使用 login_as 方法？

这完全取决于您使用的身份验证系统。如果您使用的是 Devise，则可以使用 Warden 提供的测试助手，这会使身份验证系统短路。这比让每个测试发送额外的 HTTP 请求来登录用户要高效得多。

实际上，登录步骤应该由专门针对身份验证系统的单独测试（功能/系统规范）来涵盖。

如果您自己拼凑了一些东西，则可以存根提供用户的方法，也可以完成直接发布到登录用户的方法的步骤。集成测试使用一种模拟浏览器中 cookie 处理的机制。

我不知道应该做什么，但为什么这是你的测试应该关注的事情？这似乎是内部悬空的，而且很臭。valid_attributes["code"].next!