单元测试中Mock的外部资源入参除可读性外是否有其他实际作用？

使用具体参数代替It.IsAny<Guid>除了可读性之外，还有以下几个实际作用：

• 验证参数传递正确性：如果你的业务代码中存在参数传错的问题（比如不小心把其他变量而非入参objectID传给了GetObjectFromApi），用It.IsAny的测试完全无法识别这类问题，只要方法被调用就会命中Mock规则。而如果Setup时指定了你测试用例传入的具体Guid值，只要实际传入的参数不匹配，Mock规则就不会命中，方法会返回类型默认值，你的断言会直接失败，就能快速定位到参数传递错误的bug。
• 适配多返回值的测试场景：如果同一个测试用例中需要模拟同一个方法不同参数返回不同结果的逻辑，It.IsAny完全无法满足需求，只有指定具体参数才能区分不同的返回规则。比如你需要测试「传入合法ID返回成功、传入非法ID返回404」的逻辑，必须给两个不同的ID分别设置对应的返回值才能完成测试。
• 精准控制Mock生效范围：当业务逻辑中会多次调用GetObjectFromApi时，It.IsAny会让所有调用都命中同一个Mock返回，很容易掩盖逻辑中重复调用、错误调用的问题。指定具体参数可以精确控制哪次调用返回什么结果，还可以搭配Verify方法验证方法是否按预期的参数、预期的次数被调用。

另外补充你当前代码的一个隐藏问题：你业务代码中CreateObject的入参是可空的Guid?类型，但你当前Setup的是It.IsAny<Guid>（非空Guid），如果入参传null，这条Mock规则是不会命中的，用具体参数的话可以明确覆盖可空/非空的场景。

如果你的这个测试用例的唯一目的就是验证「API返回成功时，CreateObject也返回成功」，不关心参数传递是否正确，用It.IsAny是完全没问题的。但如果你的测试还要覆盖参数传递的正确性，要么在Setup时指定具体参数，要么在测试末尾增加验证调用的逻辑：

_myApiMock.Verify(x=>x.GetObjectFromApi(Guid.Parse("81a130d2-502f-4cf1-a376-63edeb000e9f")), Times.Once);

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