FakeItEasy严格模式下方法调用验证的注意事项

在使用FakeItEasy进行单元测试时，严格模式(Strict)是一个非常有用的特性，但使用不当可能会导致预期外的异常。本文将深入探讨严格模式下的方法调用验证机制，帮助开发者避免常见陷阱。

严格模式的基本概念

FakeItEasy的严格模式通过A.Fake<T>(x => x.Strict())创建，在这种模式下，所有对fake对象的调用都必须显式配置，否则会抛出ExpectationException。这与宽松模式形成对比，宽松模式下允许未配置的调用。

常见误区分析

许多开发者会犯一个典型错误：认为A.CallTo本身就完成了方法调用的配置。例如：

var call = A.CallTo(() => featureClass.DoSomething(A<string>.Ignored));

这段代码实际上只是创建了一个调用规范(Call Specification)，但并未定义该调用的行为。在严格模式下，这样的"半成品"配置会导致测试失败。

正确的配置方式

要让严格模式下的方法调用验证正常工作，必须完整配置调用的行为。以下是几种常见方式：

1. 无返回值方法：使用DoesNothing()

A.CallTo(() => featureClass.DoSomething(A<string>.Ignored)).DoesNothing();

2. 有返回值方法：使用Returns()

A.CallTo(() => featureClass.GetValue()).Returns(42);

3. 抛出异常：使用Throws()

A.CallTo(() => featureClass.DoSomething(null)).Throws<ArgumentNullException>();

严格模式的最佳实践

1. 显式配置所有预期调用：严格模式下，每个调用都必须有明确的配置。

2. 利用变量重用调用规范：如示例所示，可以将调用规范保存到变量，便于后续验证：

var call = A.CallTo(() => featureClass.DoSomething(A<string>.Ignored));
call.DoesNothing();
// ...执行测试...
call.MustHaveHappened();

3. 考虑使用分析器：虽然编译器无法直接检测这类问题，但FakeItEasy分析器可以帮助识别未完成的调用配置。

严格模式与宽松模式的对比选择

• 严格模式：适合需要精确控制所有交互的场景，确保测试对象不会进行意外调用。
• 宽松模式：适合只关注特定调用而忽略其他的场景，测试编写更简单。

理解这两种模式的差异有助于根据测试需求做出合适选择。

总结

FakeItEasy的严格模式是确保测试精确性的强大工具，但需要开发者明确配置所有预期调用。记住A.CallTo只是开始配置的第一步，必须接着定义具体行为才能使严格模式正常工作。掌握这一细节将显著提高单元测试的质量和可靠性。