API测试用例是什么？

在互联网大行其道的今天，身为一名电商平台的程序员，必定经常与HTTP API打交道，一个常见的情况便是做API测试。抛开可以用单元测试代替的，很多时候需要真地发出HTTP请求才行。这些负责发出HTTP请求的东西可能是一行curl命令，可能是一个.js文件，也可能是一个在postman中点击按钮的操作，但不管形态如何，它们便是API测试用例。尽管名字中带有“用例”二字，但很多时候是由人来校验结果的，用例更关注发出怎样的HTTP请求。

为什么要管理它们？

不同于每天在浏览器中发生成千上万次的、平凡的HTTP（或HTTPS）请求，API测试用例是值得一番精心管理的，因为：

API测试用例通常会重复使用，因此必须将它们持久化保存。也许是保存成shell脚本，也许是保存成脚本语言源文件，也许是保存为某一款软件的数据文件；
需要为多个API编写测试用例，因此必须区分不同的API对应的测试用例。例如，负责管理业务资源的服务（比如一个管理商品数据的、提供RESTful API的服务），起码需要提供增删查改的功能，那么也就需要有增删查改对应的API测试用例；
需要为多个服务的API编写用例，因此必须区分不同的服务对应的测试用例集。例如，既然有商品服务，那么极可能还有订单服务、优惠券服务、物流服务，等等，每个服务又都有增删查改的功能，这些不同服务的API也需要各自的测试用例；
需要区分不同的运行环境。通常本地、开发、测试，以及生产环境是互相隔离的，一个用例中的参数往往不能照搬到另一个环境中。

API、服务，以及环境这三个维度上的区别，使得测试用例的数量显著增加，如不进行管理，当要用时，要么不得不从零开始再写一遍脚本，要么得翻查很久才能找到所需的用例。

用org-mode管理

org-mode是什么？

org-mode是一款Emacs编辑器的扩展，它让使用者能够用快速高效的纯文本方式来记笔记、维护待办事项、安排计划，以及编写文档。org-mode的精髓在于它的大纲组织能力，以及依托于Emacs的扩展能力，两者使其正好可以胜任管理API测试用例的工作。一个.org文件的示例如下图所示

如何用org-mode管理API测试用例？

尽管org-mode提供了丰富的功能，但只是管理API测试用例的话，并用不上太多花里胡哨的东西，只需要org-mode的大纲功能和org-babel特性即可。

首先用不同的.org文件区分不同的环境。

接着用不同层级的headline区分不同的服务、资源类型，以及API。

然后用org-mode的代码块语法来编写HTTP请求。以请求https://httpbin.org/uuid为例

1
2
3

#+BEGIN_SRC restclient
  GET https://httpbin.org/uuid
#+END_SRC

#+BEGIN_SRC和#+END_SRC分别表示开启和结束代码块，restclient表示这个代码块内的代码可以用Emacs的restclient-mode来编辑。在代码块中，GET https://httpbin.org/uuid表示以GET方法请求https://httpbin.org/uuid。

安装了restclient后，将光标定位在代码块上并按下ctrl-c '，可以进入一个单独的buffer编辑其中的源代码

最后，如果配置了org-babel，甚至可以直接在代码块上按下ctrl-c ctrl-c来发出HTTP请求。

可以看到，HTTP响应的内容会保留在这个`.org`文件中。

后记

以前我也用过其它的工具来管理API测试用例：

刚工作的时候用的是Postman，那时候Postman还是Chrome的一个插件；
后来出于对Firefox浏览器的喜爱，找了一个叫RESTClient的插件来代替postman，久而久之发觉两者的差距蛮大，终究无法代替；
接着遇到了Emacs中的restclient.el，于是用了好一段时间的纯restclient-mode（没有搭配org-mode）；
再后来开始用Mac办公了，便开始寻找Mac下的这类工具，遇到了Insomnia。如果有人找我推荐用于HTTP API测试的GUI工具的话，我会毫无不犹豫地推荐这款。

再后来，我又回到了Emacs，并用org-mode来管理这些API测试用例。目前这是最适合我的一种方式。

全文完。