RSpec测试：如何配置同一方法的不同mock返回值及测试必要性

问题1：让User.find_by按业务规则返回不同结果的写法 #

当前场景中两条Result记录天然对应不同的user_id，不需要强制按调用顺序模拟返回值，优先推荐按入参匹配的方式编写mock，避免mock和实际业务逻辑脱节：

# 提前定义测试依赖的测试对象
let(:project_id) { 1 }
let(:user1) { instance_double(User, id: 100) }
# 定义两个不同的Result测试对象，分别对应存在的用户和不存在的用户
let(:result1) { instance_double(Result, user_id: user1.id) }
let(:result2) { instance_double(Result, user_id: 999) } # 不存在的用户ID

# 先mock Result的查询结果
allow(Result).to receive(:where).with(project_id: project_id).and_return([result1, result2])

# 按不同入参分别指定User.find_by的返回值
allow(User).to receive(:find_by).with(id: user1.id).and_return(user1)
allow(User).to receive(:find_by).with(id: 999).and_return(nil)

这种写法的优势是：会严格校验每次User.find_by的入参是否符合业务逻辑，如果后续开发不小心写错了查询条件（比如误把user_id的值传错），测试会立刻报错，不会出现mock“配合”错误代码返回对的测试结果的问题。

如果需要严格按照调用顺序返回结果（比如两个查询入参完全一致的特殊场景），可以使用链式返回值的写法：

# 第一次调用返回user1，第二次调用返回nil
allow(User).to receive(:find_by).and_return(user1, nil)

注意：这种链式写法不会校验每次调用的入参，测试严谨性弱于按入参匹配的方式，仅在确实需要模拟相同入参多次调用的场景使用。

问题2：混合匹配场景的测试必要性 #

这类同时覆盖「用户匹配成功」「用户匹配失败」路径的场景完全有必要测试，是覆盖方法核心分支逻辑的关键用例，不属于冗余测试：

• 当前被测方法的核心业务规则就是「自动跳过关联用户不存在的Result记录，收集有效团队成员」，如果仅测试全匹配成功、全匹配失败的单一场景，根本无法验证这个过滤规则是否生效。比如后续开发误删了unless user.nil?的判断逻辑，全匹配成功的场景根本走不到nil判断分支，全匹配失败的场景也碰不到正常收集用户的分支，这类bug很难被发现。
• 这类2条记录的混合场景，刚好以最低成本覆盖了方法内两个分支的执行路径：一次走push(user)的正常收集分支，一次走跳过nil的过滤分支，符合单元测试最小覆盖核心逻辑的原则。
• 没有必要过度测试复杂的混合场景（比如硬凑10条记录、9个匹配1个不匹配），只要能同时触达两个分支的最小场景，就足够保障逻辑正确性，过度冗余的用例只会提升后续维护成本。

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