单元测试多个依赖关系的WCF服务

Question

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

在我的情况，我有一个服务类，其中包含几个服务方法/操作。服务类的目的是为在核心应用程序中实现的行为提供接口。这样，每个方法/操作是负责：

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

另外，该服务方法处理发生的，并且返回一个WCF故障的任何异常。

我们对IoC（DI）和AOP都使用Spring.NET。服务类由Spring实例化，它允许我们使用Spring的ParameterValidation方面来执行第2步。默认情况下，我们也使用Spring来执行第3步。

大多数情况下，所有这些工作都很棒。但是，当编写单元测试来验证服务方法的行为时，我会陷入困境，试图找出正确的方法来处理服务对多个Command对象（每个方法一个）的依赖关系。我们要清楚，我没有嘲笑Command对象（我们使用Moq，btw）的问题，也没有做黑盒测试的问题。我试图对内部逻辑进行白盒测试，例如验证步骤4是否正确执行，或者如果Command对象引发异常，则该服务会正确处理它。对于这些我使用Command对象的模拟实例。

问题是为被测对象具有多个依赖关系的情况寻找最佳实践 - 特别是当我仅对其中一个测试对象感兴趣时，我正在运行该测试。

DI的构造函数方法并不实用，因为我需要为构造函数提供尽可能多的参数，因为我在服务上执行的方法（这可能相当多）。二传手的注入与我有关，因为二传手只会出于测试的目的而存在 - 而且，在很多情况下，它们也会有很多。

该服务旨在将步骤4委托给虚拟方法，默认情况下，该方法使用Spring来实例化Command对象，但van被覆盖以使用继承 - 覆盖方法返回模拟。但是这也被证明是笨拙的。

因此，在文章上线之后涌出文章，展示各种解决方案，但正如我所说的，只用一种方法/操作反映服务，我正在寻找一些易于实现的方法的指导，在处理包含多个方法和多个依赖关系的实际服务时进行维护和扩展。

请记住，我不能使用Spring来注入mocked Command对象，因为我需要引用mock来设置它们并验证方法的行为。 （更不用说我的测试也依赖于Spring的正常工作了。）

Answer 1

听起来像你已经完成了大部分的辛勤工作。

由于您已经在使用DI容器，因此您可以简单地创建并注入拦截第3步的Mocks。然后，您可以接受DI容器接收的内容以及验证如何执行以测试前两个步骤，然后您可以模拟会返回你想要测试其余步骤的任何东西。

你已经对spring.net有了很大的依赖，并且为了注入你的嘲讽和强制测试来使用它们听起来很合理。必须有一种方法来临时修改你的配置以使用特定的模拟。如果不考虑一个简单的工厂被你的服务用来让你的Mocks到位。

Answer 2

我通常将我的服务类作为实际功能的薄外壳。在这种情况下，你可能会考虑放弃测试服务本身，但让它将所有调用委托给多个内部对象中的一个，这些内部对象将更具可测性，因为它们更具体。