一个电商项目的Web服务化改造6:单元测试4步走,构造数据、执行操作、断言、回滚
2016-05-01 11:20
411 查看
最近一直在做一个电商项目,需要把原有单系统架构的项目,改造成基于服务的架构,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之后,数据库中的数据和我们插入的数据,是否完全一样
回滚:执行操作之后,数据库回滚。也就是说,单元测试,不会“污染”数据库。
![](http://img.blog.csdn.net/20160501111834326?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQv/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center)
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" />
![](http://img.blog.csdn.net/20160501111437758?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQv/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center)
![](http://img.blog.csdn.net/20160501111450121?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQv/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center)
Dubbo的WebService的单元测试
总体流程,和Service一模一样。
需要注意的地方:
1.引入的context不一样,里面有dubbo配置。
这个地方的单元测试,注入的bean,是dubbo包装的。
而service层,是本地的bean。
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%” 。
建言:多写点单元测试,真是提高开发质量的好方法。怎么测试自己写的代码,保障代码质量,有规律可循。
个人观察:人类世界,就没有几件事是一定会发生的。一定发生的事,通常带有附加条件。
有点挑战,做完了,会有很大进步。
单元测试,在很早之前的文章已经介绍过。
可以在这里看到相关的几篇文章: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%” 。
建言:多写点单元测试,真是提高开发质量的好方法。怎么测试自己写的代码,保障代码质量,有规律可循。
个人观察:人类世界,就没有几件事是一定会发生的。一定发生的事,通常带有附加条件。
相关文章推荐
- maven项目添加websocket
- 一个电商项目的Web服务化改造6:单元测试4步走,构造数据、执行操作、断言、回滚
- c++第四次上机实验—作业
- jquery的$.extend和$.fn.extend作用及区别
- 手拖XMPP遇到问题解决地址
- www.mentalis.org/
- MyEclipse中输入变量名自动出现String
- 伸缩自如的时光轴实现
- 算法复习之二叉树的遍历
- 深入理解Java内存模型——重排序
- 二叉树的顺序存储结构
- 堆栈
- HDU 1242 Rescue(图)
- linux shell 常用基本语法
- 【HUSTOJ】1004: 求商与余数
- 链栈
- MySql: AUTO_INCREMENT
- 20145233韩昊辰 第四次实验报告
- sql server中的 SET NOCOUNT ON 的含义
- JAVA设计模式之单例模式