RSpec中FactoryBot创建Organisation时create请求未触发计数增长问题排查

从你提供的测试代码和日志来看，核心问题很明确——执行post :create接口之前，已经有一个Organisation对象被悄悄创建了，导致你的create请求因为验证失败（比如name唯一约束）没成功落地，所以数据库计数根本没变化。下面给你拆解几个最可能的原因和对应的解决办法：

1. 登录流程偷偷创建了Organisation #

你提到“初始为0，登录后变为1”，这几乎可以确定：你的测试登录步骤（不管是before(:each)钩子，还是封装的登录helper方法）里，自动生成了一个Organisation对象。常见场景包括：

• 你的Admin用户必须关联一个Organisation，登录时会自动为用户生成关联的组织；
• 或者你用来登录的测试工厂（比如create(:admin)），在创建Admin时依赖创建了Organisation。

解决思路：

• 先去检查登录相关的代码/工厂定义，看看是不是隐式创建了Organisation；
• 如果这个默认创建的Organisation不是当前测试需要的，可以修改工厂或登录逻辑，取消自动创建；
• 或者在当前测试用例的before块里手动清理掉这个多余的组织：

  before do
    login_as(admin_user) # 你的登录方法
    Organisation.destroy_all # 清除登录时生成的Organisation
  end
  

2. FactoryBot工厂的回调/关联触发了自动保存 #

虽然attributes_for(:organisation)默认只会生成属性哈希，不会创建数据库记录，但如果你的Organisation工厂里有特殊的回调（比如after(:build)），或者关联了其他会自动保存的对象，就可能意外创建记录。

排查方式：

• 打开spec/factories/organisations.rb，检查有没有after(:build)、after(:create)这类回调，或者关联了需要自动保存的模型；
• 可以在测试的expect do块前加一行调试代码：puts "Before create: #{Organisation.count}"，确认是不是调用attributes_for之后计数就变了。

3. 测试数据清理机制失效 #

RSpec默认会用数据库事务在每个测试用例后回滚数据，避免测试间的污染。但如果你的测试配置修改了清理策略，或者有地方手动提交了事务，就可能导致上一个测试的残留数据影响当前测试。

解决办法：

• 检查spec/rails_helper.rb里的数据库清理配置，确保用的是默认的:transaction策略；
• 如果用的是:truncation，确认配置正确，每个测试后都会清空表数据；
• 可以在测试用例开头加一句断言，验证初始状态：expect(Organisation.count).to eq(0)，确保测试开始前数据库是干净的。

4. Create接口的验证拦截了请求 #

从日志里的Organisation Exists查询能看出来，你的Organisation模型有name字段的唯一验证，而attributes_for(:organisation)生成的name刚好和登录时创建的那个重复了，所以create请求直接因为验证失败返回错误，根本没保存新对象。

解决思路：

• 给工厂配置序列生成唯一name，避免重复：

  factory :organisation do
    sequence(:name) { |n| "Organisation #{n}" }
    # 其他属性定义
  end
  

• 或者在测试里手动指定一个绝对唯一的name：

  post :create, params: { organisation: attributes_for(:organisation, name: "Unique-#{SecureRandom.uuid}")}, xhr: true
  

总结 #

优先排查登录流程自动创建Organisation这个点，这是最符合你描述的场景。然后再检查工厂配置和数据清理机制，确保create请求用的参数能通过模型验证，这样测试就能正常触发计数增长了。

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