一個電商專案的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
Dubbo的WebService的單元測試
總體流程,和Service一模一樣。
需要注意的地方:
1.引入的context不一樣,裡面有dubbo配置。
這個地方的單元測試,注入的bean,是dubbo包裝的。
而service層,是本地的bean。
2.呼叫dubbo服務時,“事務”不再自己本地的控制範圍內,因此,執行操作之後,資料無法回滾。
單元測試結束,資料庫中多了“髒資料” ,需要手動清除。
因此,我覺得dubbo服務方,應該使用單元測試專門配置的庫。 //設定自動回滾
單元測試,在很早之前的文章已經介紹過。
可以在這裡看到相關的幾篇文章: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%” 。
建言:多寫點單元測試,真是提高開發質量的好方法。怎麼測試自己寫的程式碼,保障程式碼質量,有規律可循。
個人觀察:人類世界,就沒有幾件事是一定會發生的。一定發生的事,通常帶有附加條件。
3.有相關人士認為,dubbo的WebService沒有提供服務,因為service經過測試了,dubbo就是簡單的包裝了下,只有1個是對的,其它的就沒啥問題。
我本人認為這純粹是“過於自信” 、“僥倖”的心理,單元測試本身的目的之一,就是讓程式自動化地發現問題,至少要在預期之內。
當程式有所改動,重新執行一遍測試,就可能發現新的問題。
或者說,這是個概率問題。service層是對的,dubbo包裝的WebService很可能不會有問題,但我認為它不可能做到“100%” 。
建言:多寫點單元測試,真是提高開發質量的好方法。怎麼測試自己寫的程式碼,保障程式碼質量,有規律可循。
個人觀察:人類世界,就沒有幾件事是一定會發生的。一定發生的事,通常帶有附加條件。
相關文章
- 一個電商專案的Web服務化改造Web
- 一個電商專案的Web服務化改造7:Dubbo服務的呼叫,4個專案Web
- 一個電商專案的Web服務化改造2:現有專案的5個問題Web
- DBUNITS的單元測試事務回滾
- 一個電商專案的Web服務化改造4:方案和架構,通用介面的定義和實現Web架構
- 一個電商專案的Web服務化改造3:改進方案の規範和約定、單表、單一職責Web
- [譯]重新思考單元測試斷言
- 程式碼重構與單元測試——測試專案(二)
- 搞定Go單元測試(三)—— 斷言(testify)Go
- JUnit 單元測試斷言推薦 AssertJ
- 如何執行指定的單元測試
- .NET 專案中的單元測試
- Web專案架構優化單臺機器到叢集服務Web架構優化
- MySQL構造測試資料MySql
- 走進單元測試一:初認Unit Test
- javascript單元測試框架mocha 和 斷言庫 assertJavaScript框架
- 為vue的專案新增單元測試Vue
- 12個強大的Web服務測試工具Web
- web自動化測試框架-01 搭建基礎架構並執行一個樣例Web框架架構
- Spring Boot單元測試之服務層測試總結Spring Boot
- 測試開發之單元測試-禪道結合ZTF驅動單元測試執行
- JB的測試之旅-測試資料的準備/構造
- github如何回滾單個檔案Github
- Maven執行和跳過單元測試Maven
- 程式碼重構與單元測試——重構1的單元測試(四)
- C語言單元測試C語言
- PHP 單元測試與資料庫測試PHP資料庫
- Flutter 初始專案單元測試解讀Flutter
- Golang 單元測試執行 _test.go 中的某個 func 方法Golang
- 深度理解React專案的服務端渲染改造React服務端
- Angular單元測試如何只執行指定的測試用例,提高測試速度Angular
- Golang 單元測試 - 資料層Golang
- db2 構造測試資料DB2
- 回滾操作、回滾段的理解
- Angular如何對包含了HTTP請求的服務類進行單元測試AngularHTTP
- 用 GIN 構建一個 WEB 服務Web
- 使用 Xunit.DependencyInjection 改造測試專案
- unittest 單元測試框架教程 1-執行測試指令碼框架指令碼