一个电商项目的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之后,数据库中的数据和我们插入的数据,是否完全一样
回滚:执行操作之后,数据库回滚。也就是说,单元测试,不会“污染”数据库。
    一个电商项目的Web服务化改造6:单元测试4步走,构造数据、执行操作、断言、回滚

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" />

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

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%” 。

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

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

上一篇:Android——横屏和竖屏的切换,以及明文密码的显示


下一篇:简单的C++11线程池实现