.net - 对具有多个依赖项的 WCF 服务进行单元测试

Question

我当然希望有人能帮助缓解我的沮丧。我正在尝试找到一种好方法来对我的 WCF 服务实现类进行单元测试，但我发现提供解决方案的每个资源都仅限于仅具有单一方法/操作的服务。

就我而言，我有一个服务类，其中包含多个服务方法/操作。服务类的目的是提供在核心应用程序中实现的行为的接口(interface)。因此，每个方法/操作负责:

1. 接受来自请求对象来电者
2. 验证对象的属性
3. 创建一个实例适用的 Command 对象执行操作
4. 映射Request对象的Command 对象的属性。
5. 执行Command对象
6. 将结果映射到响应对象
7. 将响应返回给调用者

此外，服务方法会处理发生的任何异常并返回 WCF 错误。

我们使用 Spring.NET 来实现 IoC (DI) 和 AOP。服务类由 Spring 实例化，这允许我们使用 Spring 的 ParameterValidation 方面来执行步骤 2。默认情况下，我们也使用 Spring 来执行步骤 3。

在大多数情况下，所有这些都运行良好。然而，当需要编写单元测试来验证服务方法的行为时，我陷入了困境，试图找出处理服务对多个命令对象(每个方法一个)的依赖关系的正确方法。

让我们明确一点，我在模拟 Command 对象时没有问题(我们使用 Moq，顺便说一句)，在进行黑盒测试时也没有问题。我正在尝试对内部逻辑进行白盒测试，例如验证步骤 4 是否正确执行，或者如果 Command 对象抛出异常，服务是否正确处理它。对于这些，我使用 Command 对象的模拟实例。

问题是为被测试对象具有多个依赖项的场景找到最佳实践 - 特别是当我只对我正在运行的测试中的其中一个依赖项感兴趣时。

DI 的构造函数方法并不实用，因为我需要为构造函数提供与在服务上使用方法一样多的参数(而且可能会很多)。 Setter 注入(inject)让我担心，因为 Setter 的存在只是为了测试的目的 - 而且，在很多情况下，它们的数量会很多。

该服务旨在将步骤 4 委托(delegate)给一个虚拟方法，默认情况下，该方法使用 Spring 实例化 Command 对象，但可以使用继承和覆盖方法进行重写以返回模拟。但事实证明这也很笨拙。

因此，在网上阅读了一篇又一篇展示各种解决方案的文章之后，但正如我所说，仅反射(reflect)具有一种方法/操作的服务，我正在寻找一种易于实现、维护的方法的指导并在处理包含多个方法和多个依赖项的实际服务时进行扩展。

请记住，我无法使用 Spring 注入(inject)模拟的 Command 对象，因为我需要引用模拟来设置它们并验证方法的行为。 (更不用说我的测试也依赖于 Spring 正常工作。)

Answer 1

我通常让我的服务类只是实际功能的薄薄的外观。在这种情况下，您可能会考虑放弃测试服务本身，而是将所有调用委托(delegate)给多个内部对象之一，这将更容易单独测试，因为它们会更具体。