【问题标题】:how to separate business logic in RestAssured如何在 RestAssured 中分离业务逻辑
【发布时间】:2023-03-30 12:35:02
【问题描述】:

我们有 REST 网络服务。它通过 JSON 数据表示进行操作。我想提供功能测试。我打算使用RestAssured framework。它提供了可理解的方法来测试输出 json 的正确性。

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

但是出现了一个问题:如果json结构发生变化,所有的测试都无效。例如,如果field 应重命名为field2,我们将修复所有出现field 的测试。这个问题与网页测试问题非常相似,我们应该检查一些网页元素的存在等。它通过页面对象模式引入解决。是否存在用于测试 REST api 的类似解决方案,或者您能建议一些优雅的解决方案吗?

【问题讨论】:

    标签: java json rest testing


    【解决方案1】:

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

    不过看起来 REST-Assured 已经提供了测试 JSON 响应的特定部分所需的所有功能:

    JSON example

    JSON Advanced Examples

    Using JSON Path

    您甚至可以map objects 然后对构造的对象做任何您想做的事情,例如验证和操作。

    更多示例请参见here

    【讨论】:

    • 如果您觉得您的问题仍未得到充分回答,请编辑并添加更多详细信息。
    • 感谢您提供有用的链接。看来我应该做以下事情:1.创建java类,2.将从webservice获得的json反序列化为这些类,3.为这些类编写验证方法4.在我的测试中使用上面提到的验证方法。在 json 更改的情况下,我应该更改 java 类的字段名称并相应地修复验证方法,但测试仍然是正确的。如果我错了,请纠正我
    • 我认为这取决于所需测试的深度(和长度 - 时间)。我过去几乎完全按照您的描述完成了工作,并编写了一个框架来比较生成的实际对象与预期对象(或相关部分)。涉及的成本并非微不足道 - 1. 编写框架 2. 维护框架和您的对象(使它们与响应保持同步)。如果这看起来有点矫枉过正,您可以轻松地测试响应的相关部分,而无需先使用 JSON 路径等执行到对象的映射。
    • 对不起,这是在以前的项目/角色中,无论如何都是在 C# 中。我使用了AutoMapperExpected Objects 库——也许你能找到类似的Java 库?
    【解决方案2】:

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

    那么如何使用 JSON 呢? 好吧,您可以使用正则表达式,但它可能会变得非常混乱,或者您可以使用类似 XPath 的 JSON 查询:

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

    所以在你的情况下,编写可靠的测试更多的是关于你评估的内容,而不是你用来做它的框架。

    【讨论】:

      【解决方案3】:

      REST API(特别是公共)中的更改不如 GUI 中频繁。当 API 中的更改被引入时,它们应该被标记为新版本并且不要破坏旧版本(在大多数情况下)。所以让你的测试尽可能简单,不引入额外的模式,这将有一些好处——你可以很容易地把它们扔掉并编写新的。更高的测试框架复杂性提供了更高的维护成本。您可以在 REST-Assured 中以任何方式创建 ResponseSpecification 并在断言中重用它。

      【讨论】:

        猜你喜欢
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2013-12-15
        • 2014-09-04
        • 1970-01-01
        • 1970-01-01
        相关资源
        最近更新 更多