Closed artemptushkin closed 2 years ago
What has generated your Pact file? Are you able to provide the complete file?
@uglyog like this:
"response": {
"status": 200,
"headers": {
"access-control-allow-credentials": "true",
"access-control-allow-headers": "Content-Type, Authorization",
"access-control-allow-methods": "POST, GET, PUT, HEAD, DELETE, OPTIONS, PATCH",
"content-type": "application/json, charset=utf-8"
}
}
Released 4.1.24 and 4.2.9
@uglyog this is still broken 4.2.14
Pact content:
"headers": {
"access-control-allow-credentials": "true",
"access-control-allow-headers": "Content-Type, Authorization",
"access-control-allow-methods": "POST, GET, PUT, HEAD, DELETE, OPTIONS, PATCH",
"content-type": "application/json, charset=utf-8"
}
tests output:
returns a response which
has status code 201 (OK)
includes headers
"access-control-allow-credentials" with value "true" (OK)
"access-control-allow-headers" with value "Content-Type, Authorization" (FAILED)
"access-control-allow-methods" with value "POST, GET, PUT, HEAD, DELETE, OPTIONS, PATCH" (FAILED)
"content-type" with value "application/json, charset=utf-8" (FAILED)
has a matching body (OK)
Failures:
1) Verifying a pact between tenant-portal and users - Invites an end user includes headers "access-control-allow-headers" with value "[Content-Type, Authorization]"
1.1) header: Expected header 'access-control-allow-headers' to have value 'Content-Type' but was 'Origin'
1.2) header: Expected header 'access-control-allow-headers' to have value 'Authorization' but was 'X-Requested-With'
1.5) header: Expected header 'access-control-allow-methods' to have value 'POST' but was 'GET'
1.6) header: Expected header 'access-control-allow-methods' to have value 'GET' but was 'POST'
1.7) header: Expected header 'access-control-allow-methods' to have value 'HEAD' but was 'DELETE'
1.8) header: Expected header 'access-control-allow-methods' to have value 'DELETE' but was 'OPTIONS'
1.9) header: Expected header 'access-control-allow-methods' to have value 'OPTIONS' but was 'PATCH'
1.10) header: Expected header 'access-control-allow-methods' to have value 'PATCH' but was ''
1.11) header: Expected a header 'content-type' but was missing
I just realized that this is a matter of order now... It works like equals if there are no matchers
.
I just changed the order of headers and this is ok, seems like no issue, thanks.
So, the best way to do it in contains
way is to write a custom matcher on the consumer side.
I migrate from
au.com.dius.pact.provider:junit:4.1.11
to4.2.7
, same issue with4.1.23
Some tests started failing on:
Pact looks like this:
The provider response headers looks like this:
Obviously, headers are identical, should match. Case sensitive difference it has only, but it isn't the problem as I see in debug: it reaches this line
Looks like it splits the actual response headers and then fails to match. Is this something expected?