wcf - 对 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 channel ，而是通过单元测试组成服务的实际类。一旦您测试了服务本身(您应该能够获得接近 100% 的覆盖率)，您就不需要将其参与客户端测试。

对于客户端单元测试，您模拟服务。 WCF 实际上使这对您来说变得非常容易，因为每个 WCF 客户端都实现一个接口(interface)；如果您通常在代码中使用 FooService 或 FooServiceSoapClient，请将其更改为使用相应的 IFooService 或 FooServiceSoap代理类实现。然后您可以编写自己的 MockFooService 来实现相同的接口(interface)并在您的客户端测试中使用它。

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

双工有点棘手，但请记住，双工服务也应该基于接口(interface)；甚至 MSDN example引入了一个 ICalculatorDuplexCallback。回调将是接口(interface)，所以就像您可以在客户端模拟服务方法一样，您可以在服务端模拟客户端回调。只需拥有用于服务单元测试的模拟/假回调。

Mark Seeman 有一篇关于 Unit-Testing Duplex WCF Clients 的非常好的博客文章，示例代码和所有。您应该读一读，我认为它会对您有所帮助。