今天谈下在服务实施过程中对于接口服务的单元测试。前提是基于SOA实施方法论中，服务规范和服务契约先行模式下的单元测试。对于做过软件开发的应该都清楚，要实现整个业务系统从前端页面点击开始的单元测试往往是很难的，而对于接口服务层进行单元测试是最容易的，因此今天重点讨论的是对于接口服务本身的自动化单元测试话题。
前提：从顶向下的开发模式，即基于标准的WSDL文件进行WS服务的开发
在这种模式下，首先根据服务规范生成相应的WSDL和XSD服务契约设计文件，然后业务系统可以导入WSDL文件，采用类似CXF开发框架等进行WS服务的开发，在这里以SOAP WS服务进行说明。
在服务开发完成后，需要进行单元测试，就ESB服务集成商来说需要做如下几个方面内容。
首先，验证业务系统开发的WS服务是否是严格按照当初约定的WSDL契约文件的要求进行开发的，即最基本的服务合规性测试。如果是采用SOAP UI工具，我们很容易对这点进行验证，如果不是基于最初的WSDL文件，往往进行服务测试的就会报异常。
其次，对WSDL文件中要求的字段类型进行验证，当然对于这点也是如果不符合，服务测试会直接报错。在字段类型验证后，还需要进一步进行字段本身是否允许为空的验证。这两个内容也是进行单元测试必须进行验证的内容点。
最后，模拟数据进行服务实际的调用测试，即我们可以自定义或配置模拟数据的产生规则，包括字符，数字和日期等各种类型的数据如何模拟产生，我们都可以进行规则定义，在定义规则完成后通过产生的模拟数据进行服务调用。注意在这里更多的是确认服务提供方的服务能够正常返回，因为自动化测试的时候很难真正模拟出实际真实的业务数据，只要服务能够正常返回（不管是否有结果输出）即可。
可以看到，在服务规范和服务契约制定完成后，以上内容都可以通过自动化的单元测试完成，而不需要太多的人为干预和人工操作。在自动化的单元测试完成后，再有测试人员接入实际准备真实的业务数据进行接口服务的业务规则和逻辑的测试。
在ESB服务总线实施的时候应注意到，对于服务准入测试（包括单元测试）没有通过的时候，应该直接退回给服务提供方进行相关问题的修改，而不是将服务直接发布给消费方进行联调测试。也可以讲对于服务的准入测试更多的是服务技术合规性的测试，而对于服务联调测试才是真正根据实际的业务交互场景进行接口的业务规则和校验逻辑类测试工作。
在服务实施过程中，开发自动化的单元测试工具和测试模拟器应该是一个能够提升整体实施效率，提升服务测试质量的关键工作。
