Home
1、集成测试的道 1.1 目前集成测试的面临困境
对于集成测试，一直都存在一个良好的愿景，能有一套稳定的集成测试CASE保证旧功能的正确性。在上线发布之时，只要批量跑一次原有的集成测试CASE，
就能有效的检验和回归系统之前的功能是否正确，系统之前的功能有没有被本次开发的新功能破坏。
进而保证我们的系统的每次迭代都是稳固的，不会造成系统功能的倒退。
然而，理想是丰满的，现实却是骨感的。为了维护一套集成测试CASE，往往耗费了大量的精力，而效果却收效甚微。大量的时间和精力耗费在了维护集成测试功能所依赖的第
三方 来源的数据上。比如DB中的数据，比如第三方远程RPC接口返回的数据。因此我们疲于应付，而业务的紧迫成了压倒集成测试的最后一根稻草，最后不得不放弃集成
测试或者慢慢 这些CASE疏于维护，最终废弃
最大的困难在于：
(1)依赖的第三方的接口包括DAO中获取的DB数据难以维护
(2) 接口运行之后恢复初始态，消除运行造成的影响以便使得CASE能够重复运行
这两点耗费非常多的精力，甚至使得CASE根本无法复用或者无法编写
1.2 关于集成测试的新看法 基于1.1 旧的集成测试基于如下模型：
图一
第三部分，DAO,thrift ,rpc 这部分是没有业务逻辑的，只是数据的接入方。而这恰恰是集成测试不稳定和难以维护的根源之一。
怎么破？重要的事情说三遍，看下图，看下图，看下图。。。
图二
2、集成测试的术
2.1 现有集成测试的工具与不足 为了做到（图二）的效果，我们需要这样一个测试框架： (1)接口参数输入文档化，数据驱动测试，一个接口，从文档获取不同的参数，反复测试 (2) 内部业务服务不需MOCK，采用spring runtime依赖管理，一方面减少了mock工作量，最重要的是若采用mock就失去了集成测试的意义。集成测试所测试的就是这些内部服务交互的结果 (3) 为了去除没有业务逻辑的不稳定要素，可以将DAO,Thrift等第三方数据接入方的接口MOCK掉
目前可选的测试工具有，JUnit,spring test,JMock,easyMock,JMockit等，缺点如下：
工具 不足 JUnit 完善易用的断言机制，插件机制，和构建工具结合较好，但仅仅适用单元测试，无法胜任集成测试 spring test 能够很好的管理服务service之间的依赖，但无Mock能力，被迫维护DB以及第三方接口状态以便达到CASE复用 JMock,easyMock,JMockit。。。 对于业务service,无依赖管理能力
我们需要一款能够集合以上三种测试工具优点于一身的测试框架-- ares-integration
(为什么叫这个名字，ares是希腊神话中的战神，起个霸气一点的名字。。)
2.2 ares-integration 做了什么
实现原理很简单，通过自定义的测试运行器，将junit,spring runtime,JMockit 三者融于一体。(一定要注意，这里只支持JMockit)
最终实现了图二的要求。使得测试框架具有三者的优点：
1、参数数据输入文档化，通过注解标签 @Source，实现了数据驱动测试
2、可以加载整个spring runtime environment，使得业务service得到很好的初始化和依赖管理，这是整个集成测试存在的意义，业务service之间的交互构成了业务逻辑
3、可以将不稳定要素，同时也是业务逻辑非常轻的外部依赖（包括DAO）给MOCK掉
3、 ares-integration 使用指南 3.1 配置
3.2 例程 看图说话
csv文件如下，为了简单，例子一行一个参数，其实是支持多参数，用逗号分隔即可，比如： id, name, phone 1 , yebing, 15399988 2, test, 0988666
对于复杂参数对象，建议序列化为json,然后在测试类中反序列化为测试入参对象
spring-config.xml配置文件如下：
前面说了大量的优点，目前有一个小缺陷需要提一下： （1）目前做不到直接mock DAO或者Thrift的接口，需要在接口之上封装一层实现类，不加任何业务逻辑。然后对该类进行MOCK。 比如，DAO接口，Thrift接口上层封装一层service实现类，仅仅wraper接口DAO，接口Thrift,不写其他业务逻辑。其实按照分层要求，这也是应该实现的。 比如上面例程里面没有直接MOCK DAO接口而是mock的DAO上层封装类 SellSrcFeeRuleServiceImpl。 （2）目前MOCK框架只支持 JMockit，不是JMOCK，是JMockit 。这不算缺点，JMockit的功能是所有MOCK框架里面最强大的，是其余所有MOCK框架功能的超集 1.