为什么你一直在写假的测试用例？

乃古石林.昆明.云南 中国

作者： Eugen Paraschiv

译者： helloworldtang

目录

1.概览

2.测试状态码

3.测试媒体类型

4.测试接口返回的JSON

5.测试利器

6.依赖

7.总结

1. 概览

本教程重点介绍使用自动化IT(集成测试)测试REST API的基本原则和机制。

我们的主要目标是介绍如何测试API的可用性——示例将使用最新版本的 GitHub REST API。 对于内部应用程序，此类测试通常在部署REST API之后，作为持续集成的后期步骤运行。

在测试REST资源时，通常会有一些正交的职责需要关注：

HTTP响应代码

响应中的其他HTTP头

有效负载（JSON，XML）

每个测试用例应该只关注单个职责，并包含一个断言。清晰的关注点分离总是有好处的，并且在这种黑盒测试中就更重要了，因为通常的情况是在一开始就编写复杂的测试用例。

集成测试的另一个重要原则是坚持单一抽象层级——业务逻辑应该在更高层级的用例中完成。诸如创建请求、向服务器发送HTTP请求、处理IO等细节应该委托给第三方库，而不是自己实现并且到处散落在测试用例中。

2. 测试状态码

这是一个相当简单的测试——它用来检查一个API是否是可用的，并不会给测试用例增加太多的复杂性。

不管出于什么原因它失败了，那么在被修复之前，我们就不需要查看这个API相关的测试用例。

3. 测试媒体类型

这个测试用例确保了服务器响应的资源表述是JSON。

正如您可能已经注意到的，我们在按照一个循序渐进的方式进行测试 ——首先是响应状态码（确保接口是可用的），然后是服务器响应的媒体类型，并且只有到下一个测试用例，我们才会检查接口返回的JSON数据。

4. 测试接口返回的JSON

在上面的测试用例中，我们知道GitHub资源的默认表述是JSON，但在通常情况下，响应的Content-Type头应该与请求的Accept头一起测试——客户端通过Accept请求资源特定类型的表述，这是服务器应该遵守的。

5. 测试利器

我们将使用Jackson 2将JSON字符串反序列化成一个类型安全的Java实体：

我们只使用一个简单的工具来保持测试用例的整洁、可读性和一个比较高的抽象层级：

注意，Jackson忽略了GitHub API发送给我们的未知属性 ——这仅仅是因为GitHub上用户资源的表述变得非常复杂——我们在这里不需要其它的信息。

6. 依赖

测试工具和测试用例使用的库在Maven Central上都是可用的，如下所示：

HttpClient

Jackson 2

Hamcrest (可选的)

7. 总结

上面的示例只是完整集成测试的一部分。测试着重于确保REST API的正确性，而不必涉及更复杂的情况，譬如，以下内容都没有涉及：API的可发现性、对同一资源使用不同的表述等等。

所有这些示例和代码片段都可以在Github上找到——这是一个基于maven的项目，因此应该很容易导入和运行。