为什么空手道配置标头的行为与直接在后台设置标头不同？

Question

我编写了一个测试，调用一次 api 端点并在响应中检索一个 etag。 之后，我进行第二次调用，并将 etag 值设置为 if-none-match header。 测试如下所示：

Feature: Retrieve station properties

  Background:
    * url baseUrl
    * def contentType = 'application/vnd.whatever'
    * def accessToken = 'ey.foobar.123'
    * configure headers = { Authorization: '#("Bearer " + accessToken)', Accept: '#(contentType)' }

  Scenario: Fetch station properties once and expect a 304 on the sub-sequent request

    Given path '/api/station-properties'
    When method GET
    Then status 200
    And headers {ETag: '#notnull'}
    And def etag = responseHeaders['ETag'][0]

    Given path '/api/station-properties'
    And header If-None-Match = etag
    When method GET
    Then status 304

这基本上是可行的，但我对配置标题行不满意，因为稍后我可能会添加其他标题。 因此我考虑使用不同的方法来设置标题：

Feature: Retrieve station properties

  Background:
    * url baseUrl
    * def contentType = 'application/vnd.whatever'
    * def accessToken = 'ey.foobar.123'
    * header Authorization = 'Bearer ' + accessToken
    * header Accept = contentType

  Scenario: Fetch station properties once and expect a 304 on the sub-sequent request

    Given path '/api/station-properties'
    When method GET
    Then status 200
    And headers {ETag: '#notnull'}
    And def etag = responseHeaders['ETag'][0]

    Given path '/api/station-properties'
    And header If-None-Match = etag
    When method GET
    Then status 304

但是，在这种情况下，标题（授权和接受）在第一个 api 调用中设置，但在第二个调用中没有。

为什么会这样？

Answer 1

是的， configure规则是“坚持”多个 HTTP 调用。 因此，只需在Background进行此更改：

* configure headers = ({ Authorization: 'Bearer ' + accessToken, Accept: contentType })

好吧，是的 - 做你之前在做的事情。 现在它应该可以工作了。