对于某些需求,我已经编写了IServiceBehaviorIEndpointBehaviorIDispatchMessageInspector的实现,我所有的WCF服务都使用它们。

我需要对它们进行单元测试吗?如果是,如何对这些自定义WCF扩展点进行单元测试?我正在使用MSTest。

最佳答案

您应该进行两组测试:

  • 这些接口的自定义实现的单元测试
  • 服务的集成测试(还将涵盖接口,但在完整的实际使用设置场景中)

  • 单元测试的实现应与其他任何单元测试一样进行。这确实缩小了验证这些自定义实现的作用。普通的旧单元测试。

    但是,请注意,成功地对此类WCF位实现进行单元测试有两个主要障碍:
  • WCF上下文标头(或只是简单地放置上下文)在模拟方面将很难使用,因为它们来自静态类(OperationContext.Current)
  • 模拟一些方法参数可能是不可能的,因为它们是密封的(例如InstanceContext)或相当复杂的

  • 自然,所有这些都可以通过使用适当的技术和工具来克服:
  • 对于无法进行模拟的密封类,您只需创建实例(借助 AutoFixture 之类的工具)并手动设置对象/依赖关系图(可能很耗时,但是在大多数情况下,您不会使用全部他们)。
  • 可以模拟/存根的任何东西都应该这样做, FakeItEasy 让我们简单地存根任何类,只要它不是密封的即可(不必是接口)。处理未使用的方法参数很棒。
  • 要处理OperationContext.Current(及类似代码),您可能需要对设计进行一些更改。确切地说,所有使用当前上下文以某种方式使用的类都将需要实现protected virtual方法来公开它(或可能有用的任何其他部分,例如请求标头):
    protected virtual MessageHeaders GetContextHeaders()
    {
        return OperationContext.Current.RequestContext.RequestMessage.Headers;
    }
    

    然后,您需要创建派生的可测试类,该类将返回这些标头(或上下文或您计划使用的任何内容)的模拟/存根版本,并在单元测试中创建该类的实例。

  • 完成单元测试后,integration应该很短的路程。只需按照您在实际场景中使用的对象设置对象,然后验证它们是否按预期工作即可。

    旁注:也可以以更简单的方式完成单元测试,但是您将需要付费工具(例如Typemock Isolator,它可以模拟静态/密封类)和/或较重/复杂的类(PEX/Moles)。

    10-05 21:19
    查看更多