我当然希望有人可以帮助减轻我的挫败感。我试图找到一种好的方法来对我的WCF服务实现类进行单元测试，但是我发现提供解决方案的每个资源都仅限于只有一个方法/操作的服务。
在我的例子中，我有一个服务类，其中包含几个服务方法/操作。服务类的目的是为核心应用程序中实现的行为提供接口。因此，每个方法/操作负责：
此外，service方法处理发生的任何异常并返回WCF故障。
我们正在将Spring.NET用于IoC（DI）和AOP。服务类由Spring实例化，允许我们使用Spring的ParameterValidation方面执行第2步。默认情况下，我们也使用Spring执行第3步。
在大多数情况下，所有这些都很有效。但是，当需要编写单元测试来验证服务方法的行为时，我会陷入困境，试图找出处理服务在多个Command对象上的依赖关系的正确方法（每个方法一个）。
让我们明确一点，我没有问题模拟Command对象（我们使用Moq，顺便说一句），我也没有问题做黑盒测试。我正在尝试对内部逻辑进行白盒测试，例如验证步骤4是否正确执行，或者如果Command对象抛出异常，则服务正确处理它。对于这些我使用Command对象的模拟实例。
问题在于找到测试对象具有多个依赖关系的场景的最佳实践 - 特别是当我只对其中一个对我正在运行的测试感兴趣时。
构造函数对DI的方法是不实际的，因为我需要为构造函数提供尽可能多的参数，就像我在服务上使用方法一样（这可能相当多）。 Setter-injection让我担心，因为setter只会出于测试的目的而存在 - 而且，在许多情况下，它们会有很多。
该服务旨在将第4步委托给一个虚方法，该方法默认使用Spring来实例化Command对象，但是可以覆盖van以使用inherit-and-override方法返回模拟。但事实证明这也很笨拙。
所以，经过在线文章的演示后，演示了各种解决方案，但正如我所说，只有用一种方法/操作反映服务，我正在寻找一些易于实现，维护的方法的指导并在处理包含多个方法和多个依赖项的实际服务时进行扩展。
请记住，我不能使用Spring注入模拟的Command对象，因为我需要引用模拟以设置它们并验证方法的行为。 （更不用说我的测试也依赖于Spring正常工作。）
答案 0 :(得分：1)
我的服务类通常只是真正功能的薄外观。在这种情况下，您可能会考虑放弃测试服务本身，但让它将所有调用委托给多个内部对象中的一个，这些内部对象将更加可测试，因为它们更具体。
答案 1 :(得分：0)
听起来你已经完成了大部分的努力工作。
由于您已经在使用DI容器，或许您可以简单地创建并注入拦截步骤3的Mocks。然后您可以接收DI容器接收的内容以及验证行为如何测试前两个步骤然后您可以使用模拟返回您想要测试剩余步骤的任何内容。
你已经对spring.net有了很大的依赖，并且在注入你的模拟和强制测试以使用它们的额外距离对我来说听起来很合理。必须有一种方法可以临时修改配置以使用特定的模拟。如果不考虑一个简单的工厂供您的服务使用，以便让您的Mocks到位。