基於gin的單元測試之httptest
目前我們的後端服務提供大量的restful api介面,每次上線都需要測試那邊迴歸一遍這些介面,造成人力的浪費。正好藉著這次單元測試和持續整合,我們引入了httptest框架,結合gin來做介面單元測試。
httptest是golang官方提供的一個包,位於/src/net/http/httptest下。
其原理的話我也看了原始碼研究了下,這裡大致說下,它有一個ResponseRecorder結構體,它實現了http.ResponseWriter,同時它自身又包含了http.Response,前者是server端維度下的response,後者是client端維度下的response,也就是說,ResponseRecorder同時實現了server和client的功能。
好接下來看看如何使用httptest
httptest構建
// Get 根據特定請求uri,發起get請求返回響應
func Get(uri string, router *gin.Engine) []byte {
// 構造get請求
req := httptest.NewRequest("GET", uri, nil)
// 初始化響應
w := httptest.NewRecorder()
// 呼叫相應的handler介面
router.ServeHTTP(w, req)
// 提取響應
result := w.Result()
defer result .Body.Close()
// 讀取響應body
body,_ := ioutil.ReadAll(result.Body)
return body
}
// PostForm 根據特定請求uri和引數param,以表單形式傳遞引數,發起post請求返回響應
func PostForm(uri string, param url.Values, router *gin.Engine) []byte {
// 構造post請求
req := httptest.NewRequest("POST", uri, strings.NewReader(param.Encode()))
req.Header.Set("Content-Type" , "application/x-www-form-urlencoded")
// 初始化響應
w := httptest.NewRecorder()
// 呼叫相應handler介面
router.ServeHTTP(w, req)
// 提取響應
result := w.Result()
defer result.Body.Close()
// 讀取響應body
body, _ := ioutil.ReadAll(result.Body)
return body
}
在gin中註冊路由,並寫了兩個介面樣例
regAdmin := router.Group("/quote")
regAdmin.GET("/ge", Ge)
regAdmin.POST("/pos", Pos)
type TestForPost struct {
Strname string `form:"strname" binding:"required"`
Number int `form:"number" binding:"required"`
}
// Get介面
func Ge(c *gin.Context) {
c.String(http.StatusOK, "success")
}
// Post介面
func Pos(c *gin.Context) {
req := &TestForPost{}
if err := c.ShouldBindWith(req, binding.Form); err != nil {
fmt.Println("bind error",err)
c.JSON(http.StatusOK, gin.H{
"errno":"1",
"errmsg":"引數不匹配",
"data":"",
})
return
}
c.JSON(http.StatusOK, gin.H{
"errno":"0",
"errmsg":"Null",
"data":req,
})
}
寫單元測試
type Response struct {
Errno string `json:"errno"`
Errmsg string `json:"errmsg"`
Data TestForPost `json:"data"`
}
func TestOnGetStringRequest(t *testing.T) {
// 初始化請求地址
url:="/quote/ge"
// 發起Get請求
body := Get(url, router)
// 判斷響應是否與預期一致
if string(body) != "success" {
t.Errorf("響應字串不符,body:%v\n",string(body))
}
convey.Convey("測試GET介面", t, func() {
convey.So(string(body), convey.ShouldEqual, "success")
})
}
func TestOnPostRequestForForm(t *testing.T) {
// 初始化請求地址和請求引數
uri := "/quote/pos"
param := url.Values{
"strname":{"test"},
"number":{"1"},
}
// 發起post請求,以表單形式傳遞引數
body := PostForm2(uri, param, router)
//body := PostForm3(uri, param, router)
// 解析響應,判斷響應是否與預期一致
response := &Response{}
if err := json.Unmarshal(body, response); err != nil {
t.Errorf("解析響應出錯,err:%v\n",err)
}
t.Log(response.Data)
if response.Data.Strname != "test" {
t.Errorf("響應資料不符,errmsg:%v, data:%v\n",response.Errmsg,response.Data.Strname)
}
convey.Convey("測試POST介面", t, func() {
convey.So(response.Data.Strname, convey.ShouldEqual, "test")
})
}
完成
相關推薦
基於gin的單元測試之httptest
目前我們的後端服務提供大量的restful api介面,每次上線都需要測試那邊迴歸一遍這些介面,造成人力的浪費。正好藉著這次單元測試和持續整合,我們引入了httptest框架,結合gin來做介面單元測試。 httptest是golang官方提供的一個包,位於/
Golang單元測試之httptest使用
現在有一個需求那就是,我們需要使用Golang的net/http包中的http.Get(url)方法去向伺服器端請求資料,但是負責服務端的同事並沒有將介面實現(可能是同事太忙,把妹,喝酒,扯淡, XO
單元測試之Stub和Mock
下載 我們 並且 試用 sample 註入 mes oge new 單元測試之Stub和Mock FROM:http://www.cnblogs.com/TankXiao/archive/2012/03/06/2366073.html 在做單元測試的時候,我們會發現我
python + unittest 做單元測試之學習筆記
stl unittest 例子 gin pre log script 有關 assert 單元測試在保證開發效率、可維護性和軟件質量等方面有很重要的地位,所謂的單元測試,就是對一個類,一個模塊或者一個函數進行正確性檢測的一種測試方式。 這裏主要是就應用 python + u
論單元測試之重要性
表單 曾經 mybatis 服務 request 第一個 完成 分離 能說 單元測試的重要性不言而喻,自我開發生涯以來,從很少註釋過過場場,到非常重視。 單元測試為什麽會讓人忽視呢? 通常情況像一些查詢或者增刪改之類,拿我來說,即便報錯我大概一掃,我就知道錯誤是什麽了,該如
python筆記24-unittest單元測試之mock.patch
rom Coding int self. 錯誤 測試用例 方法 org auto 前言 上一篇python筆記23-unittest單元測試之mock對mock已經有初步的認識, 本篇繼續介紹mock裏面另一種實現方式,patch裝飾器的使用,patch() 作為函數裝飾器
補習系列-springboot 單元測試之道
try 精彩 一次 run rest spec ner hat ltm 目錄 目標 一、About 單元測試 二、About Junit 三、SpringBoot-單元測試 項目依賴 測試樣例 四、Mock測試 五、最後 目標 了解 單元測試的背景 了解如何 利用
單元測試之Mock(Moq)
inter 商品 void 簡單 calc 不用 準備 targe ted Mock翻譯為“嘲弄”,其實就是偽造一個對象用於測試。在單元測試中,被測試方法依賴於其他對象時,為了測試簡單一般“偽造”一個這個對象;這樣做的目的: 不用考慮依賴對象的復雜性(方便準備測試數據)
java單元測試之如何實現非同步介面的測試案例
測試是軟體釋出的重要環節,單元測試在實際開發中是一種常用的測試方法,java單元測試主要用junit,最新是junit5,本人開發一般用junit4。因為單元測試能夠在軟體模組組合之前儘快發現問題,所以實際開發中投入產出比很高。實際使用難免會遇到非同步操作的介面測試,最常用的情景是別人家的SD
前端單元測試之Jest
概述 關於前端單元測試的好處自不必說,基礎的介紹和知識可以參考之前的部落格連結:React Native單元測試。在軟體的測試領域,測試主要分為:單元測試、整合測試和功能測試。 單元測試:在計算機程式設計中,單元測試(英語:Unit Testing)又稱為模組測試, 是針對程式模組(軟體設計的最小單
spring boot單元測試之druid NullPointException
最近在使用spring boot 對 Controller 進行單元測試時,發現 druid 竟然丟擲了空指標異常。原因是,使用了druid的監控,需要經過druid的 Filter 攔截器,但是spr
powermockito單元測試之深入實踐
概述 由於最近工作需要, 在專案中要做單元測試, 以達到指定的測試用例覆蓋率指標。專案中我們引入的powermockito來編寫測試用例, JaCoCo來監控單元測試覆蓋率。關於框架的選擇, 網上討論mockito和powermockito孰優孰劣的文章眾多, 這裡就不多做闡述, 讀者如有興趣可自行了解。
phpunit 單元測試之程式碼覆蓋率
最近團隊在不斷完善專案中的單元測試用例,會用到程式碼覆蓋率分析,本來以為 homestead 應該預設安裝了 xdebug ,所以使用 phpunit --coverage-html ./tests/codeCoverage 來生成 html 報告,但是執行後提示如下錯誤 Error: No
談談單元測試之(四):測試工具 TestNG
前言 上一篇文章《測試工具 JUnit 4》中提到了 JUnit 4,並對 JUnit 4 做了簡單的討論,這篇文章我們將要圍繞另一款測試工具討論 —— TestNG。其實,這篇文章應該寫在《測試工具 JUnit 3》之後,和《測試工具 JU
談談單元測試之(三):測試工具 JUnit 4
前言 上一篇文章《測試工具 JUnit 3》簡單的討論了 JUnit 3 的使用以及內部的方法。這篇文章將會在 JUnit 3 的基礎上,討論一下 JUnit 4 的新特性。同時,與 JUnit 3 做一個簡單的對比。那麼,廢話就不多說了,直
談談單元測試之(二):測試工具 JUnit 3
前言 上一篇文章《 為什麼要進行煩人的單元測試?》討論了一下現階段軟體開發中,程式設計師們測試情況的現狀。這篇文章中,我打算介紹一下單元測試的工具(外掛),並且推薦大家以後在開發中,真正的用上單元測試,用好單元測試。
談談單元測試之(一):為什麼要進行煩人的單元測試?
前言 最近,在網上看到過一個調查,調查的內容是“程式設計師在專案開發中編寫單元測試的情況”。當然,至於調查的結果,我想聰明的你已經可以猜到了。高達 58.3% 的比例,一般情況下不寫單元測試,只有偶爾的情況才會寫寫。16.6%
Java單元測試之JUnit篇
JUnit4通過註解的方式來識別測試方法。目前主要註解有: @BeforeClass 全域性只會執行一次,而且是第一個執行,且必須為static void @Before 在測試方法執行之前執行,即初
[OpenStack UT] 單元測試之Monkey Patch
再說monkey patch之前先說下, python中的Test Double, Test Double就是在測試case中給某個物件做替身的意思. 用一個假物件替換. 用Test Double時, 可以有三種實現的形式, Stub,Mock object, Fake O
.NET Core單元測試之搞死開發的覆蓋率統計(coverlet + ReportGenerator )
.... 更新 and enc team port ide git 微軟 .NET Core單元測試之搞死開發的覆蓋率統計 這兩天在給項目補單元測試,dalao們要求要看一下測試覆蓋率 翻了一波官方test命令覆蓋率倒是有支持了,然而某個更新日誌裏面寫著 【“Suppor