【问题标题】:Wiremock Request Pattern Matching with Request ParametersWiremock 请求模式与请求参数匹配
【发布时间】:2019-05-29 20:43:30
【问题描述】:

我在 Spring Boot 2.1.5 应用程序中使用 spock 和 wiremock 进行功能测试。传入的url是:

/mockedserver/v1/Items('1010873195')/Products?$format=json

是的,这是一个非常奇怪的网址,但我对此无能为力。

我在 JSON 中设置了一个路径匹配器:

{
  "request": {
    "method": "GET",
    "url": "/mockedserver/v1/Items('1010873195')/Products.*",
    "queryParams" : {
      "$format": "json"
    },
    "headers": {
      "x-csrf-token": "",
      "Accept": "application/json",
      "Content-Type": "application/json"
    }
  },
  "response": {
    "headers": {
      "Content-Type": "application/json"
    },
    "status": 200,
    "bodyFileName": "/../responses/mockedserver/get-products/1010873195-success-200.json"
  }
}

如您所见,我在“queryParams”块中对看起来很奇怪的请求参数进行了建模。这不起作用,所以我将正则表达式 .* 放在 url 的末尾。

两者都给了我结果:

                                               Request was not matched
                                               =======================

-----------------------------------------------------------------------------------------------------------------------
| Closest stub                                             | Request                                                  |
-----------------------------------------------------------------------------------------------------------------------
                                                           |
GET                                                        | GET
/mockedserver/v1/Items('1010873195')/Produ                 | /mockedserver/v1/Items('1010873195')/Produ<<<<< URL does not match
cts                                                        | cts?$format=json
                                                           |
                                                           |
-----------------------------------------------------------------------------------------------------------------------

如您所见,它匹配,除了最后的参数部分,基本上,我不关心参数,所以我希望只是通配符。

一种可能性是$ 标志把事情弄得一团糟,我应该逃避它吗?如果有,怎么做?

另一个是问号?。我试过用\?\\? 来逃避它,但都没有成功。

仅关于此处看起来很重要的请求块部分:

    "method": "GET",
    "url": "/mockedserver/v1/Items('1010873195')/Products.*",
    "queryParams" : {
      "$format": "json"
    },

我有seen it said elsewhere,如果您使用urlPath 代替url,WireMock 会将没有匹配参数的额外标头或查询参数视为“不关心,无论如何都匹配”。但正如错误输出所示,这里的情况似乎并非如此。

进一步讨论 从那以后,我尝试了各种组合,按照建议将urlPathurlPattern 甚至urlPathPattern 替换为url。所有这些导致:

                                               Request was not matched
                                               =======================

-----------------------------------------------------------------------------------------------------------------------
| Closest stub                                             | Request                                                  |
-----------------------------------------------------------------------------------------------------------------------
                                                           |
GET                                                        | GET
                                                           | /mockedserver/v1/Items('1010873195')/Produ<<<<< URL does not match. URLs must start with a /
                                                           | cts?$format=json
                                                           |
                                                           |
-----------------------------------------------------------------------------------------------------------------------

我也试过这个有和没有queryParams 块,以防这有助于匹配,但它似乎没有任何效果。 我开始怀疑在stubFor 调用中是否需要设置其他标志?

【问题讨论】:

    标签: spring-boot groovy spock wiremock


    【解决方案1】:

    已修复:基本上,您需要 urlPath、没有 queryParams 和基于字符串的正则表达式模式,我解决了这些问题:

    /^\\/mockedserver\\/v1\\/Items\('[0-9]{10}'\)\\/Products/
    

    基本上,它归结为正确的组合。

    【讨论】:

      【解决方案2】:

      我认为您需要在映射中尝试“urlPathPattern”或“urlPath”而不是“url”,如下所示:

      "urlPathPattern": "/mockedserver/v1/Items('1010873195')/Products.*"
      

      【讨论】:

      • 感谢您的建议:我已经尝试过urlPathurlPattern,虽然我无法记录它,但urlPathPattern 代替了url。所有这些都导致根本没有匹配的存根。换句话说,closest match: /
      • 我刚刚用进一步的发现更新了这个问题,包括你的建议@AntonHinisty
      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 2018-09-08
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2021-02-22
      • 1970-01-01
      相关资源
      最近更新 更多