共计 3608 个字符，预计需要花费 10 分钟才能阅读完成。
一、什么是 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”)。
