如何在RestAssured中分离业务逻辑

Question

我们有REST网络服务。它在JSON数据表示上运行。我想提供功能测试。我计划使用RestAssured framework。它为测试输出json的正确性提供了可理解的方法。

示例，get("/method").then().assertThat().body("obj.field", equalTo(5));

但是出现了一个问题：如果json结构发生变化，所有测试都将无效。例如，如果field应重命名为field2，我们将使用field的出现次数修复所有测试。问题非常类似于网页测试问题，我们应该检查一些网页元素的存在等。它是通过Page Object模式引入的。是否存在一些类似的解决方案用于测试REST API？或者您可以建议一些优雅的解决方案吗？

Answer 1

在您的问题中给出的示例中，您验证了响应对象的整个主体，在这种情况下，您很可能会创建脆弱的测试。

然而，看起来REST-Assured已经提供了测试JSON响应的特定部分所需的所有功能：

JSON example

JSON Advanced Examples

Using JSON Path

您甚至可以map objects然后对构建的对象执行任何操作，例如验证和操作。

有关更多示例，请参阅here。

Answer 2

就像使用HTML页面一样，编写较少暴露于更改的测试的一种方法是使用策略来定位要评估的目标。 使用网页，您可以使用XPath查询，CSS Seletor或直接使用id来避免对祖先的依赖。

那么如何使用JSON呢？ 那么你可以使用正则表达式，但它可能会变得非常混乱，或者你可以使用类似XPath的查询来搜索JSON：

http://goessner.net/articles/JsonPath/
  http://defiantjs.com/

因此，在您的情况下，编写可靠的测试更多的是您评估的内容，而不是您用来执行此操作的框架。

Answer 3

REST API（特别是公共）中的更改频率低于GUI。当引入API的更改时，应使用新版本标记，并且不要破坏旧版本（在大多数情况下）。因此，尽可能简化测试，不引入额外的模式，这将带来一些好处 - 您可以轻松地将它们扔掉并编写新的。 Hihger测试框架的复杂性提供了更高的维护成本。在REST-Assured中，您可以创建ResponseSpecification并在断言中重用它。