一个电商项目的Web服务化改造6：单元测试4步走，构造数据、执行操作、断言、回滚

  最近一直在做一个电商项目，需要把原有单系统架构的项目，改造成基于服务的架构，SOA。

    有点挑战，做完了，会有很大进步。

单元测试，在很早之前的文章已经介绍过。 
    可以在这里看到相关的几篇文章：http://blog.csdn.net/FansUnion/article/category/1333595/2

在这次Web服务化改造中，理论上有4层需要测试。
1. Mybatis的mapper层，mapper.java和,mapper.xml，
2. 负责数据组装的Dao层，Dao.java。
3.负责业务逻辑的Service层，Service.java。
4.经过Dubbo包装之后的WebService层，WebService.java。

考虑到实际情况，mapper层没有写相关的单元测试，只写了另外3层的。
  同时需要注意到的是，Service层和WebService层，内部代码可以说是完全一样，唯一不同的是，Service调用的是本地代码，而WebService调用的是远程的代码。

Dao层的单元测试：初始化数据，然后就是“单元测试标准4步”，构造数据-执行操作-断言-回滚。
初始化：Spring和JUnit结合提供了注解支持，配置dataSource.xml就可以了。
构造数据：手动构造brand对象
执行操作：我们自己写的add、get等方法
断言：增加add之后，数据库中的数据和我们插入的数据，是否完全一样
回滚：执行操作之后，数据库回滚。也就是说，单元测试，不会“污染”数据库。
    

Service层的单元测试
 
     Service层和Dao层流程基本一致，初始化+标准4步。
    不同点：service初始化，需要配置spring上下文，上下文文件中，再引入dataSource.xml。
   spring-context-nodubbo.xml

   <context:component-scan base-package="cn.fansunion.webservice.service">

</context:component-scan>

   <import resource="classpath*:spring-dataSource.xml" />

Dubbo的WebService的单元测试
 总体流程，和Service一模一样。
需要注意的地方： 
1.引入的context不一样,里面有dubbo配置。
   这个地方的单元测试，注入的bean，是dubbo包装的。
  而service层，是本地的bean。
   

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
	   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	   xmlns:dubbo="http://code.alibabatech.com/schema/dubbo"
	   xsi:schemaLocation="http://www.springframework.org/schema/beanshttp://www.springframework.org/schema/beans/spring-beans.xsd
	   http://code.alibabatech.com/schema/dubbo http://code.alibabatech.com/schema/dubbo/dubbo.xsd
	   ">
 
	<dubbo:application name="ws-demo" />
 
	<dubbo:registry address="N/A" />
 
	<dubbo:reference id="brandService" interface="cn.fansunion.webservice.service.front.BrandService" version="1.0.0"
				   url="webservice://127.0.0.1:9000/cn.fansunion.webservice.service.front.BrandService"/>
 
	<dubbo:reference id="redmanService" interface="cn.fansunion.webservice.service.front.RedmanService" version="1.0.0"
				   url="webservice://127.0.0.1:9000/cn.fansunion.webservice.service.front.RedmanService"/>
</beans>

2.调用dubbo服务时，“事务”不再自己本地的控制范围内，因此，执行操作之后，数据无法回滚。
单元测试结束，数据库中多了“脏数据” ，需要手动清除。
因此，我觉得dubbo服务方，应该使用单元测试专门配置的库。 

//设置自动回滚

//@TransactionConfiguration(transactionManager = "transactionManager", defaultRollback = true)  

//@Transactional  

//测试远程的Dubbo管理的Service

@ContextConfiguration(locations={"classpath:spring-context-dubbo.xml"})

@RunWith(SpringJUnit4ClassRunner.class)

public class BaseServiceTest

3.有相关人士认为，dubbo的WebService没有提供服务，因为service经过测试了，dubbo就是简单的包装了下，只有1个是对的，其它的就没啥问题。
  我本人认为这纯粹是“过于自信” 、“侥幸”的心理，单元测试本身的目的之一，就是让程序自动化地发现问题，至少要在预期之内。
当程序有所改动，重新执行一遍测试，就可能发现新的问题。

或者说，这是个概率问题。service层是对的，dubbo包装的WebService很可能不会有问题，但我认为它不可能做到“100%” 。

建言：多写点单元测试，真是提高开发质量的好方法。怎么测试自己写的代码，保障代码质量，有规律可循。

个人观察：人类世界，就没有几件事是一定会发生的。一定发生的事，通常带有附加条件。