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

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

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

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

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

不过在这种情况下，头（Authorization和Accept）在第一次api调用时设置，但在第二次调用时没有设置

---

为什么会出现这种情况？

是的，规则是

configure

is to。因此，只需在

背景中进行此更改即可：

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

嗯，是的，做你之前做的事。现在它应该可以工作了。
thx用于指出+链接！