一、什么是rest-assured
現(xiàn)在，越來(lái)越多的 Web 應(yīng)用轉(zhuǎn)向了RESTful的架構(gòu)，很多產(chǎn)品和應(yīng)用暴露給用戶的往往就是一組 REST API，這 樣有一個(gè)好處，用戶可以根據(jù)需要，調(diào)用不同的 API，整合出自己的應(yīng)用出來(lái)。從這個(gè)角度來(lái)講，Web 開發(fā)的成本會(huì)越來(lái)越低，人們不必再維護(hù)自己的信息孤島，而是使用 REST API 這種組合模式。

那么，作為 REST API 的提供者，如何確保 API 的穩(wěn)定性與正確性呢？全面系統(tǒng)的測(cè)試是必不可少的。Java 程 序員常常借助于 JUnit 來(lái)測(cè)試自己的 REST API，不，應(yīng)該這樣說(shuō)，Java 程序員常常借助于JUnit 來(lái)測(cè)試 REST API的實(shí)現(xiàn)！從某種角度來(lái)說(shuō)，這是一種“白盒測(cè)試”，Java 程序員清楚地知道正在測(cè)試的是哪個(gè)類、哪個(gè)方 法，而不是從用戶的角度出發(fā)，測(cè)試的是哪個(gè)REST API。

Rest-Assured 是一套由 Java 實(shí)現(xiàn)的 REST API測(cè)試框架，它是一個(gè)輕量級(jí)的REST API 客戶端，可以直接編寫代碼向服務(wù)器端發(fā)起 HTTP請(qǐng)求，并驗(yàn)證返回結(jié)果；它的語(yǔ)法非常簡(jiǎn)潔，是一種專為測(cè)試 REST API 而設(shè)計(jì)的 DSL。使用 Rest-Assured 測(cè)試 REST API，就和真正的用戶使用 REST API 一樣，只不過(guò) Rest-Assured 讓這一切變得自動(dòng)化了。

二、模擬get請(qǐng)求
雪球網(wǎng)是一個(gè)股票投資網(wǎng)站，你可以使用網(wǎng)站的搜索功能來(lái)查詢股票信息，比如我們想查詢sougou的信息，下 面利用了charles分析工具來(lái)查看請(qǐng)求和回答：

這是一個(gè)Get請(qǐng)求，返回的內(nèi)容格式如下：

現(xiàn)在，我們使用 Rest-Assured 來(lái)編寫一個(gè)簡(jiǎn)單的測(cè)試程序調(diào)用相同的Get請(qǐng)求：

• 第一步，我們要判斷這是什么格式數(shù)據(jù)：json

• 第二步，確定請(qǐng)求地址：從charles的結(jié)果中獲取y為https://xueqiu.com/stock/search.json

• 第三步，填寫表單：從chrome瀏覽器檢查結(jié)果中查詢r(jià)equest的query信息是code：sougou
  

我們的代碼也很簡(jiǎn)單：

返回的結(jié)果卻很殘酷：

與登陸賬號(hào)，刷新頁(yè)面有關(guān)的話，我首先想到了cookie，網(wǎng)站都用cookie來(lái)保存賬號(hào)相關(guān)信息，于是加入 cookie：

返回結(jié)果正確，你問(wèn)我驚不驚喜，老實(shí)回答，不驚喜。因?yàn)槲腋悴幻靼诪槭裁匆粋€(gè)查詢需要cookie驗(yàn)證，如果 不加cookie，返回的信息卻是沒(méi)有登陸!

顯然，我的cookie并不包含登陸信息，因?yàn)槲覊焊蜎](méi)有登陸，當(dāng)然這是網(wǎng)站的設(shè)計(jì)，與rest-assured無(wú)關(guān)。

更進(jìn)一步
怎么區(qū)別xml與json

答:你看就知道了嘛，xml長(zhǎng)這個(gè)樣子

json長(zhǎng)這個(gè)樣子

given，when，then分別是什么

答：given用于放置需要的參數(shù)，比如上面例子中，我將訪問(wèn)參數(shù)：code和cookie放到了given里；when用于填 寫要訪問(wèn)的url；then進(jìn)行斷言，來(lái)來(lái)判斷結(jié)果是否正確。

三、模擬post請(qǐng)求
有的時(shí)候，我們想提交表單，這種情況下使用get會(huì)非常被動(dòng)，于是post登場(chǎng)了。

下面是代碼。

我相信此時(shí)你的內(nèi)心是這樣的。

別著急，下面我會(huì)講清楚…

在我大萬(wàn)維網(wǎng)世界中，TCP就像汽車，我們用TCP來(lái)運(yùn)輸數(shù)據(jù)，它很可靠，從來(lái)不會(huì)發(fā)生丟件少件的現(xiàn)象。但是 如果路上跑的全是看起來(lái)一模一樣的汽車，那這個(gè)世界看起來(lái)是一團(tuán)混亂，非常緊急的警車可能被前面的汽車攔堵在路上，整個(gè)交通系統(tǒng)一定會(huì)癱瘓。

交通規(guī)則HTTP誕生了。HTTP給汽車運(yùn)輸設(shè)定了好幾個(gè)服務(wù)類別，有GET, POST, PUT, DELETE等等，HTTP規(guī)定，當(dāng)執(zhí)行GET請(qǐng)求的時(shí)候，要給汽車貼上GET的標(biāo)簽（設(shè)置method為GET），而且要求 把傳送的數(shù)據(jù)放在車頂上（url中）以方便記錄。如果是POST請(qǐng)求，就要在車上貼上POST的標(biāo)簽，并把貨物放 在車廂里。當(dāng)然，你也可以在GET的時(shí)候往車廂內(nèi)偷偷藏點(diǎn)貨物，但是這是很不光彩；也可以在POST的時(shí)候在車頂上也放一些數(shù)據(jù)，讓人覺得傻乎乎的。HTTP只是個(gè)行為準(zhǔn)則，而TCP才是GET和POST怎么實(shí)現(xiàn)的基本。

四、使用斷言
使用equalTo
在前面，我們使用了equalTo判斷值是否是“搜狗”:

它的作用顯而易見：判斷值是否相同。比如下面的例子

如果你想驗(yàn)證lottoId是否等于5，你可以這樣做：

使用hasItems

你可以用再次equalTo()，對(duì)winnerId[0]用一次，對(duì)winnerId[1]用一次。

哈哈，當(dāng)然不是。你可以使用hasItems，它是這么使用的：

從根開始定位

額…請(qǐng)教王師傅。

比如下面的代碼，我們可以這么驗(yàn)證：

使用find

答對(duì)了，請(qǐng)一定要記住xml和json的區(qū)別，不要混談，那么你能編寫一個(gè)測(cè)試來(lái)驗(yàn)證雜貨（groceries）的類別是 否包含巧克力（Chocolate）和咖啡（Coffe）嗎？

這確實(shí)達(dá)到了我的要求，但代碼明顯有很多bug，如果我更改了category的位置，像下面這樣，你的代碼就不 適用了，我不難為你了，請(qǐng)王師傅來(lái)解答吧：

find的用法展示的很清楚，不需要我多講，當(dāng)然還有一點(diǎn)要注意，你可以這么使用find：

**是個(gè)特殊用法，它從xml文檔根部開始，進(jìn)行深度搜索，直到找到符合我們需要的項(xiàng)。

使用findAll

現(xiàn)在我手頭只有20塊錢，我只能買兩本書，我更喜歡世紀(jì)的諺語(yǔ)和白鯨記，現(xiàn)在的任務(wù)是：挑選出格低于10的書籍，并且標(biāo)題是“世紀(jì)的諺語(yǔ)(Sayings of the Century)”和“白鯨記(Moby Dick)”

對(duì)的，這時(shí)候應(yīng)該使用findAll，可以粗魯?shù)恼J(rèn)為多個(gè)find的疊加。findAll可以篩選出一批符合要求的數(shù)據(jù)，而 find只能篩選出一個(gè)符合要求的數(shù)據(jù)，這就像是我們只能挑出一個(gè)人領(lǐng)取一等獎(jiǎng)，但有很多人可以拿參與獎(jiǎng)， 兩個(gè)方法都有自己的用武之地。

下面的代碼展示了findAll的用法：

五、提取想要的值
有時(shí)候，我們并不想驗(yàn)證是否正確，我們只想取出這個(gè)值以進(jìn)行下一步處理，比如我想取出next的鏈接：/title?page=2，這種情況怎么辦呢？

下面的代碼判斷內(nèi)容是不是JSON，并且標(biāo)題是My Title的話，就返回href鏈接/title?page=2，這個(gè)值被存放在nextTitleLink中，以供我們以后使用。

當(dāng)然，有兩點(diǎn)需要注意：

• 返回類型是Response，我們可以用http://Response.xxx來(lái)二次提取想要的值。

• extract().后面是response()方法，不要寫錯(cuò)了。

六、更改默認(rèn)值
rest-assured有很多默認(rèn)值，也正因?yàn)槿绱耍枰覀兊奶畹膮?shù)可以很少，也可以很多，就像畫畫一樣，可以很精致，也可以很簡(jiǎn)潔。

修改端口

rest-assured發(fā)起請(qǐng)求時(shí)，默認(rèn)使用的host為localhost，端口為8080，如果你想使用不同的端口，你可以這樣做：

或者是這樣

或者

修改baseURI和basePath
你也可能改變默認(rèn)的baseURI、basePath

這就意味著，類似 get("/hello") 這樣的一個(gè)請(qǐng)求，其實(shí)完整的請(qǐng)求為：http://myhost.com:80/resource/hello?， 并且使用基礎(chǔ)授權(quán)認(rèn)證"username" and “password”。

其他
其他的默認(rèn)值可以參考下面：

重置
你也可以重置為標(biāo)準(zhǔn)的baseURL(localhost)、basePath(空)、標(biāo)準(zhǔn)端口port(8080)、標(biāo)準(zhǔn)根路徑root path(" ")，默 認(rèn)的認(rèn)證scheme(none)以及URL編碼(true)，通過(guò)下面的方法重置：

七、specification
在不同的測(cè)試用例當(dāng)中，我們可能會(huì)有重復(fù)的響應(yīng)斷言或者是請(qǐng)求參數(shù)，那么我們可以將重復(fù)的這一部分提取出來(lái)定義一個(gè)規(guī)范或者模板，這樣的話在后續(xù)的測(cè)試用例當(dāng)中就可以使用這個(gè)規(guī)范模板了。

為了達(dá)到這個(gè)效果，我們可以使用RequestSpecBuilder或 ResponseSpecBuilder來(lái)實(shí)現(xiàn)，它們之間的區(qū)別 是，前者用在請(qǐng)求中，后者則用在body中。

ResponseSpecification重用
例如，你想在多個(gè)測(cè)試用例中，都使用這樣的斷言：判斷響應(yīng)狀態(tài)碼是否為200，并且Json數(shù)組"x.y"的大小是否 等于2。你可以定義一個(gè)ResponseSpecBuilder來(lái)實(shí)現(xiàn)這個(gè)功能：

在這個(gè)例子中，需要重用的兩個(gè)斷言數(shù)據(jù)被定義在"responseSpec"，并且與另外一個(gè)body斷言合并，組成了這 個(gè)測(cè)試用例中全部的斷言，那么這個(gè)測(cè)試用例需要全部斷言都通過(guò)用例結(jié)果才會(huì)通過(guò)，一旦其中一個(gè)斷言失 敗，則測(cè)試用例的測(cè)試結(jié)果為失敗。

RequestSpecification重用
同樣，假如你想在多個(gè)測(cè)試用例中重用請(qǐng)求數(shù)據(jù)，可以通過(guò)下面的代碼來(lái)實(shí)現(xiàn)：

這里的請(qǐng)求數(shù)據(jù)被合并在"requestSpec"中，所以這個(gè)請(qǐng)求包含了兩個(gè)參數(shù)(“parameter1"和"parameter2”)以及一 個(gè)頭部(“header1”)。

總結(jié)
本文就rest-assured的基本功能進(jìn)行舉例說(shuō)明，其中例子大多來(lái)自于官方文檔，同時(shí)我也建議大家多去閱讀該開 發(fā)文檔，其中有很多我們沒(méi)有講到的東西。