一、什么是rest-assured
当初，越来越多的 Web 利用转向了RESTful的架构，很多产品和利用裸露给用户的往往就是一组 REST API，这 样有一个益处，用户能够依据须要，调用不同的 API，整合出本人的利用进去。从这个角度来讲，Web 开发的老本会越来越低，人们不用再保护本人的信息孤岛，而是应用 REST API 这种组合模式。

那么，作为 REST API 的提供者，如何确保 API 的稳定性与正确性呢？全面零碎的测试是必不可少的。Java 程 序员经常借助于 JUnit 来测试本人的 REST API，不，应该这样说，Java 程序员经常借助于JUnit 来测试 REST API的实现！从某种角度来说，这是一种“白盒测试”，Java 程序员分明地晓得正在测试的是哪个类、哪个方 法，而不是从用户的角度登程，测试的是哪个REST API。

Rest-Assured 是一套由 Java 实现的 REST API测试框架，它是一个轻量级的REST API 客户端，能够间接编写代码向服务器端发动 HTTP申请，并验证返回后果；它的语法十分简洁，是一种专为测试 REST API 而设计的 DSL。应用 Rest-Assured 测试 REST API，就和真正的用户应用 REST API 一样，只不过 Rest-Assured 让这所有变得自动化了。

二、模仿get申请
雪球网是一个股票投资网站，你能够应用网站的搜寻性能来查问股票信息，比方咱们想查问sougou的信息，下 面利用了charles剖析工具来查看申请和答复：

这是一个Get申请，返回的内容格局如下：

当初，咱们应用 Rest-Assured 来编写一个简略的测试程序调用雷同的Get申请：

  • 第一步，咱们要判断这是什么格局数据：json
  • 第二步，确定申请地址：从charles的后果中获取y为https://xueqiu.com/stock/sear...
  • 第三步，填写表单：从chrome浏览器查看后果中查问request的query信息是code：sougou

咱们的代码也很简略：

返回的后果却很残暴：

与登陆账号，刷新页面无关的话，我首先想到了cookie，网站都用cookie来保留账号相干信息，于是退出 cookie：

返回后果正确，你问我惊不惊喜，诚实答复，不惊喜。因为我搞不明确为什么一个查问须要cookie验证，如果 不加cookie，返回的信息却是没有登陆!

显然，我的cookie并不蕴含登陆信息，因为我压根就没有登陆，当然这是网站的设计，与rest-assured无关。

更进一步
怎么区别xml与json

答:你看就晓得了嘛，xml长这个样子

json长这个样子

given，when，then别离是什么

答：given用于搁置须要的参数，比方下面例子中，我将拜访参数：code和cookie放到了given里；when用于填 写要拜访的url；then进行断言，来来判断后果是否正确。

三、模仿post申请
有的时候，咱们想提交表单，这种状况下应用get会十分被动，于是post退场了。

上面是代码。

我置信此时你的心田是这样的。

别着急，上面我会讲清楚...
在我大万维网世界中，TCP就像汽车，咱们用TCP来运输数据，它很牢靠，从来不会产生丢件少件的景象。然而 如果路上跑的全是看起来截然不同的汽车，那这个世界看起来是一团凌乱，十分紧急的警车可能被后面的汽车拦堵在路上，整个交通系统肯定会瘫痪。

为了防止这种状况产生，交通规则HTTP诞生了。HTTP给汽车运输设定了好几个服务类别，有GET, POST, PUT, DELETE等等，HTTP规定，当执行GET申请的时候，要给汽车贴上GET的标签（设置method为GET），而且要求 把传送的数据放在车顶上（url中）以不便记录。如果是POST申请，就要在车上贴上POST的标签，并把货物放 在车厢里。当然，你也能够在GET的时候往车厢内偷偷藏点货物，然而这是很不荣耀；也能够在POST的时候在车顶上也放一些数据，让人感觉傻乎乎的。HTTP只是个行为准则，而TCP才是GET和POST怎么实现的根本。

四、应用断言
应用equalTo
在后面，咱们应用了equalTo判断值是否是“搜狗”:

它的作用不言而喻：判断值是否雷同。比方上面的例子

如果你想验证lottoId是否等于5，你能够这样做：

应用hasItems


你能够用再次equalTo()，对winnerId[0]用一次，对winnerId[1]用一次。

哈哈，当然不是。你能够应用hasItems，它是这么应用的：

从根开始定位


额....求教王师傅。

比方上面的代码，咱们能够这么验证：

应用find


答对了，请肯定要记住xml和json的区别，不要混谈，那么你能编写一个测试来验证杂货（groceries）的类别是 否蕴含巧克力（Chocolate）和咖啡（Coffe）吗？

这的确达到了我的要求，但代码显著有很多bug，如果我更改了category的地位，像上面这样，你的代码就不 实用了，我不难为你了，请王师傅来解答吧：


find的用法展现的很分明，不须要我多讲，当然还有一点要留神，你能够这么应用find：

**是个非凡用法，它从xml文档根部开始，进行深度搜寻，直到找到合乎咱们须要的项。

应用findAll

当初我手头只有20块钱，我只能买两本书，我更喜爱世纪的谚语和白鲸记，当初的工作是：筛选出格低于10的书籍，并且题目是“世纪的谚语(Sayings of the Century)”和“白鲸记(Moby Dick)”

对的，这时候应该应用findAll，能够粗鲁的认为多个find的叠加。findAll能够筛选出一批符合要求的数据，而 find只能筛选出一个符合要求的数据，这就像是咱们只能挑出一个人支付一等奖，但有很多人能够拿参加奖， 两个办法都有本人的用武之地。

上面的代码展现了findAll的用法：

五、提取想要的值
有时候，咱们并不想验证是否正确，咱们只想取出这个值以进行下一步解决，比方我想取出next的链接：/title?page=2，这种状况怎么办呢？

上面的代码判断内容是不是JSON，并且题目是My Title的话，就返回href链接/title?page=2，这个值被寄存在nextTitleLink中，以供咱们当前应用。


当然，有两点须要留神：

  • 返回类型是Response，咱们能够用Response.xxx来二次提取想要的值。
  • extract().前面是response()办法，不要写错了。

六、更改默认值
rest-assured有很多默认值，也正因为如此，须要咱们的填的参数能够很少，也能够很多，就像画画一样，能够很粗劣，也能够很简洁。

批改端口
rest-assured发动申请时，默认应用的host为localhost，端口为8080，如果你想应用不同的端口，你能够这样做：

或者是这样

或者

批改baseURI和basePath
你也可能扭转默认的baseURI、basePath

这就意味着，相似 get("/hello") 这样的一个申请，其实残缺的申请为：http://myhost.com:80/resource... ， 并且应用根底受权认证"username" and "password"。

其余
其余的默认值能够参考上面：

重置
你也能够重置为规范的baseURL(localhost)、basePath(空)、规范端口port(8080)、规范根门路root path(" ")，默 认的认证scheme(none)以及URL编码(true)，通过上面的办法重置：

七、specification
在不同的测试用例当中，咱们可能会有反复的响应断言或者是申请参数，那么咱们能够将反复的这一部分提取进去定义一个标准或者模板，这样的话在后续的测试用例当中就能够应用这个标准模板了。

为了达到这个成果，咱们能够应用RequestSpecBuilder或 ResponseSpecBuilder来实现，它们之间的区别 是，前者用在申请中，后者则用在body中。

ResponseSpecification重用
例如，你想在多个测试用例中，都应用这样的断言：判断响应状态码是否为200，并且Json数组"x.y"的大小是否 等于2。你能够定义一个ResponseSpecBuilder来实现这个性能：

在这个例子中，须要重用的两个断言数据被定义在"responseSpec"，并且与另外一个body断言合并，组成了这 个测试用例中全副的断言，那么这个测试用例须要全副断言都通过用例后果才会通过，一旦其中一个断言失 败，则测试用例的测试后果为失败。

RequestSpecification重用
同样，如果你想在多个测试用例中重用申请数据，能够通过上面的代码来实现：

这里的申请数据被合并在"requestSpec"中，所以这个申请蕴含了两个参数("parameter1"和"parameter2")以及一 个头部("header1")。