factory_bot中build_stubbed策略含义及与create、build的区别

"stubbed out" 的具体含义 #

这里的stubbed out是测试场景下的桩逻辑实现：factory_bot会生成一个行为和真实持久化模型对象高度一致的实例，但全程不会触发任何数据库连接，所有和数据库交互相关的方法都会被预先拦截，直接返回预设结果，不会真的执行数据库读写操作。
具体被桩替换的逻辑包括：

• 自动生成符合主键格式的非空假ID，和真实数据库生成的自增ID/UUID格式无差异
• 拦截new_record?、persisted?这类持久化状态判断方法，固定返回「对象已持久化」的结果
• 拦截save、update、destroy、未预加载关联访问这类会触发数据库IO的方法，调用时不会真的连库，要么返回对应stub生成的关联对象，要么抛出明确的stub调用提示
• 关联对象默认也会走build_stubbed策略生成，全链路不触达数据库

和create、build策略的核心区别 #

三种策略的行为差异可以直接对照：

• create：完整走ORM的实例化、参数校验、数据库写入全流程，生成的对象是真实存在于测试库的持久化记录，所有行为和生产环境查询出的对象完全一致，缺点是存在数据库IO开销，测试运行速度慢。
• build：仅在内存中实例化模型对象、填充预定义属性，不会写入数据库；生成的对象主键ID默认为nil，调用persisted?返回false、new_record?返回true，属于未保存的新对象；如果手动调用save方法、访问未提前加载的关联，仍然会真实连接数据库执行操作，没有做任何拦截。
• build_stubbed：核心差异集中在三点：
  • 全程零数据库IO：对象生成、关联填充全流程不连库，执行速度远快于create，同时比build更安全，不会因为误调用持久化方法、关联加载意外触发数据库操作拖慢测试速度。
  • 行为更贴近真实持久化对象：和build生成的未保存对象不同，build_stubbed生成的对象ID非空、持久化状态判断返回已保存，不需要额外写入数据库就能通过大多数业务逻辑里的持久化状态校验。
  • 测试边界更清晰：如果测试代码中调用了被stub的数据库操作方法，会直接抛出明确错误，提醒当前测试场景不应该触达数据库，避免写出逻辑越界的慢测试。

适用场景参考：如果单元测试不需要验证数据库写入逻辑、不需要执行SQL级别的复杂查询/事务/约束校验，仅测试模型自身的业务方法、参数传递逻辑，build_stubbed是效率最高的选择。

内容的提问来源于stack exchange，提问作者Code-Apprentice