单元测试SOA WCF系统......发现难以获得良好的覆盖率

Question

我们目前正在用基于.NET3.5的现代SOA WCF系统取代已有20年历史的基于C的系统.我们的行业需要严格的测试,包括良好的自动化单元测试覆盖率 我们遇到了问题,但是将我们的SOA系统单元测试到接近基于C的系统进行单元测试的程度.

最大的问题是系统中的大多数方法实际上都依赖于跨服务边界调用代码,例如我们是大量数据驱动但我们不直接在我们的系统中访问数据库:我们调用WCF数据访问服务.

在visual studio中运行任何单元测试几乎是不可能的,因为做几乎任何事都会导致某种类型的跨服务调用.如果它不是数据访问其他服务之一.我估计我们可以获得大约5%的覆盖率.

我看到很多人都在努力测试SOA,所以我认为这对我们来说并不是独一无二的.问题是QA会质疑我们为什么不对系统进行单元测试.

老实说,我认为VSTS单元测试更像是回归测试,而不是验证(适合使用)工具.单元测试SOA有哪些选择？在人们的经验中实现良好的覆盖是否现实？有没有办法模拟数据访问服务(或任何服务:注意我们不使用WCF代理)或者我们是否必须向QA解释单元测试能力在过去20年中倒退了......

欢迎任何形式的建议,我想这是一个普遍的意见问题.

Answer 1

我不得不说,对SOA进行单元测试很像是对其他任何东西进行单元测试.如果有什么它应该更容易,因为它迫使你隔离依赖.

单元测试通常不应跨越服务边界.实际上,服务的概念是完全独立且不透明.您直接测试服务 - 不是通过WCF通道,而是通过单元测试组成服务的实际类.一旦您测试了服务本身(您应该能够获得接近100%的覆盖率),您就不需要将其纳入客户端测试.

对于客户端单元测试,您可以模拟服务.WCF实际上让你很容易,因为每个WCF客户端都实现了一个接口; 如果您通常在代码中使用FooServiceor FooServiceSoapClient,请将其更改为使用相应的代理类IFooService或FooServiceSoap代理类实现的代码.然后,您可以编写自己的MockFooService实现相同的接口并在客户端测试中使用它.

有时在这里绊倒人们的部分原因是服务可以根据具体的消息做出截然不同的事情.但是,涉及服务接口的客户端测试通常应该每次测试只测试一个或两个特定消息,因此使用Rhino Mocks等工具模拟给定客户端测试所需的确切请求/响应很容易.

双工有点棘手,但请记住,双工服务也应该基于接口; 甚至MSDN示例也引入了一个ICalculatorDuplexCallback.回调将是接口,因此就像您可以在客户端模拟服务方法一样,您可以在服务端模拟客户端回调.只需要用于服务单元测试的模拟/假回调.

Mark Seeman有一篇关于单元测试双工WCF客户端的博客文章,包括示例代码和所有内容.你应该给它一个阅读,我想它会帮助你在这里.