·数据驱动测试的数据管理

  这里有两个值得一提的相关问题。首先，为了降低最后一个示例的大量移动部分，建议不要使用配置文件抽象数据源信息。实际上，如果有多个开发人员运行测试，他们可能都使用不同的数据源信息。虽然本文并不会说明如何实现，但是DataSource属性允许可以完成。在线MSDN文档有关于这方面的解释。第二，每次运行测试时，在示例中可以使用SQL脚本轻松地创建和安装包含测试数据的数据库。当然，这项技术比较适合用于已经存在的测试数据库，而对于其它环境也许并不能良好工作。管理数据库是一个问题，并且没有适合所有情况的方法。但是抽象数据源信息到配置文件，提供了适合不同方法的灵活性。

  ·测试Web服务代码

  开发人员不仅可以本地化运行单元测试代码，还能远程运行代码，例如Web服务。采用与本地代码相同的方法编写纯粹的Web服务测试驱动开发显然不太可能，因为测试Web服务时，实际上是本地测试Web服务代理。因为这并不是Web服务客户端的典型开发方法，所以开发人员不能真正编写调用代理的测试，然后再编写满足测试的代理。有经验的Web服务开发人员建议，首先生成Web服务描述语言（Web Services Description Language，WSDL）规则，然后再分别开发基于规则的Web服务和Web服务客户端实现。因为过于复杂，所以客户端代理代码和服务器端说明代码通常都工具自动生成。

  然而，可以首先生成WSDL规则，再生成基于此规则的客户端代理，然后在测试中调用代理。由于Web服务还不存在，执行测试会失败。所以必须实现并部署按照WSDL规则的Web服务。直到最终传递给测试，生成Web服务都可能出现问题。虽然并不是纯粹的测试驱动开发，但是非常接近。在本示例中，使用Visual Studio传递最简单的路径，然后向解决方案添加Web服务项目，并对其进行测试。右击任意Web服务方法，通过与本地方法相同的途径生成测试。图12显示如何操作。这对于生成Web服务代理和使用该代理的测试有一定影响。如下代码中显示了生成的带有少量装饰性修改的测试方法。
 

图12  测试Web服务