Erich Buri
03/20/2023, 10:21 PMaddInteraction()
method (willRespondWith
).
But the resulting pact-json file would have the expressiveness to do what I want.
I can't find a matcher that would yield the matchingRules
that I'm looking for.
As an example:
Instead of
"$.body.angebote.CLASSIC.angebotStatusFachlich": {
"match": "type"
},
"$.body.angebote.COMFORT.angebotStatusFachlich": {
"match": "type"
},
I would like it to generate:
"$.body.angebote.*.angebotStatusFachlich": {
"match": "type"
},
Another example:
merkmale: {
DOMIZILLAND_VN: {
art: 400054,
code: 40,
},
MERKMAL_PARTNERART_VN: {
art: 432,
code: 433,
},
},
=> The keys will vary (DOMIZILLAND_VN, MERKMAL_PARTNERART_VN), so I would like to be able to generate rules like:
"$.body.merkmale.*.code": {
"match": "type"
},
We're currently using Pact 9.x - anything in there that would allow me to write the pact-test in a spec-File that will actually produce matching rules with wildcards? Manually writing the pact-files is not really maintainable.
Would there be a solution in 10.x?
I saw on github discussions about eachKey-Matchers and I think that goes in the right direction, but I could not find that in the API for 9.x
(I read that this kind of API is supposedly bad design, but it works really good with JavaScript/TS Frontends and it is now what it is.)
Any help is appreciated.Erich Buri
03/22/2023, 10:37 AM"combine": "AND",
or "combine": "OR",
I'm interested in that feature, but I don't see how the I can apply it with pact-js. It always writes "combine": "AND",
How can I achieve an OR-Combination of Matchers?
The API I need to test provides Options of different types, and depending on the type, the type of the remaining fields change:
{
OPTION_A: {
"type": "Number",
"value": 0,
"allowedValues": [
0,
500,
1000,
2000
]
},
OPTION_B: {
"type": "String",
"value": "No",
"allowedValues": [
"Yes",
"No",
"Maybe"
]
}
}
Tiago Andre Ranghetti
03/22/2023, 9:30 PMnestjs-pact
+ @pact-foundation/pact
+ kafka (or any other messaging queue).
Do you have any example to share or any suggestion? Thank you!jyothi B
03/24/2023, 1:36 PMUlises Cervino
03/27/2023, 1:52 PMatLeastOneLike
meant "check this array, and at least 1 element in it should be like the template", but it turns out that's not it. What's the best way to check that there's at least 1 item in an array of varied items that conforms to the template?Ulises Cervino
03/27/2023, 1:58 PMarrayContaining
that I'm looking for?Ganesh Walunj
04/07/2023, 9:35 AMRobert
04/12/2023, 7:21 AMpact-node@10.17.6: WARN: Ignoring unsupported matching rules {"match"=>"type"} for path $['body']['someData']['pData']['items'][*]@['type']
⢠Weirdly pact is adding and removing the matching rule during every test run. So the pact is also changed every time
"$.body.someData.pData.items[*].@id": {
"match": "type"
},
"$.body.someData.pData.items[*].@type": {
"match": "type"
},
I also saw there is a similar issue with the pact-php. https://github.com/pact-foundation/pact-php/issues/162 , but there is no progress since 3 years. So my question is should I raise an issue in pact-js or try to push the pact-php issue?Beth Pennell
04/12/2023, 8:30 AMTam Norris
04/12/2023, 10:59 AMTien Vo
04/12/2023, 12:05 PMpact-js
at the first time and it work fine. But then I work on another computer, then go back and ran yarn install
and got these errors:
⢠Cannot find module 'code-point-at'
⢠Cannot find module 'number-is-nan'
I fix it by running sudo npm install -g number-is-nan
and sudo npm install -g code-point-at
Not sure it's pact-js
's bug, or we can ignore these kinds of errors.
If this is a bug, more details in this thread.Yousaf Nabi (pactflow.io)
Syam K
04/18/2023, 1:53 PMyarn test:consumer
yarn run v1.22.17
$ jest __tests__/contract/consumer --runInBand --setupFiles ./__tests__/helpers/pactSetup.js --setupTestFrameworkScriptFile=./__tests__/helpers/pactTestWrapper.js
RUNS __tests__/contract/consumer/ClientsConsumer.spec.js
[14:40:14.473] ERROR (23284): pact@11.0.2: Test failed for the following reasons:
Mock server failed with the following mismatches:
0) The following request was expected but not received:
Method: GET
Path: /api/employees
Headers:
Accept: application/json
\__tests__\contract\consumer\ClientsConsumer.spec.js:81
expect(response.headers['Content-Type']).toBe("application/json"); ^
TypeError: Cannot read properties of undefined (reading 'Content-Type')
Yousaf Nabi (pactflow.io)
Tam Norris
04/21/2023, 1:56 PMJames Braund
04/26/2023, 4:15 PM/token
endpoint. As per the OIDC spec, we've implemented the /token
endpoint to accept a request with Content-Type
of application/x-www-form-urlencoded
.
The intention was for us to use fromProviderState
to match the body and allow a valid authentication grant to be generated and injected by the provider tests. However, it seems Pact doesn't currently support matchers on unstructured body content (https://github.com/pact-foundation/pact-js/issues/767).
Second attempt - we looked at ignoring the body in the contract spec, and then using reqFilter
in the Verifier
to generated and inject the authN grant into the body. But we then ran into an outstanding bug which means unstructured content doesn't get injected correctly into the request body (https://github.com/pact-foundation/pact-js/issues/884).
Is there another approach we're missing here? And is there any priority being given to address either of these issues?
Many thanks!Edwin Raju
04/28/2023, 11:13 AMMartin GrĂźhn
04/28/2023, 6:26 PMwithRequestMultipartFileUpload
to write a consumer test for one of our endpoints. The function is defined as
public withRequestMultipartFileUpload(
req: V3Request,
contentType: string,
file: string,
mimePartName: string
): PactV3 {
[...]
}
, and I was wondering where the mimePartName
value is meant to be collected from during the test-execution.
I gather that the the contentType
field is taken from the content-type
request header, and that the binary file
is taken from the form data body.
Where is the mimePartName
represented?
The test-implementation for this part looks something like
.withRequestMultipartFileUpload(
{
method: 'POST',
path: endpoint
},
'multipart/form-data',
`${__dirname}/${testFileName}`,
'image/png' // <--- I know that's the mime-type, since the back-end will tell me so
)
During the test-execution, I get the debug-output:
2023-04-28T17:22:00.413534Z DEBUG tokio-runtime-worker pact_matching::matchers: String -> String: comparing 'multipart/form-data; boundary=R9kK5VpobMo1Lz7p' to 'multipart/form-data; boundary=--------------------------379308910942565113614489' ==> true cascaded=false matcher=Regex("multipart/form-data;(\\s*charset=[^;]*;)?\\s*boundary=.*")
2023-04-28T17:22:00.413554Z DEBUG tokio-runtime-worker pact_matching: --> Mismatches: [BodyMismatch { path: "$", expected: Some(b"image/png"), actual: None, mismatch: "Expected a MIME part 'image/png' but was missing" }]
The request body of the interaction (as it is implemented by my front-end application) with the actual API-endpoint in the browser looks like shown in the attachments, and there is no mention of the mime-type in the headers as well.
Should the mimePartName
parameter of the function be made optional perhaps, as it seems to be in no way mandatory? I could ask my frond-end team to add a header or another value to the form-data, but why should they send an information that has the be gathered/verified by the back-end anyway?
Also, just FYI: I've tried to use the method withRequestBinaryFile
instead, since it does not require the mimePartName
parameter to be provided, but the test-execution with that one fails due the boundary not being known beforehand, as it is calculated each time anew:
2023-04-28T17:11:50.880036Z DEBUG tokio-runtime-worker pact_mock_server::hyper_server: Request did not match: Request did not match - HTTP Request ( method: POST, path: /assets, query: None, headers: Some({"Content-Type": ["multipart/form-data; boundary=----515823676253717799984874"]}), body: Present(68987 bytes) ) 0) Mismatch with header 'Content-Type': Expected header 'Content-Type' to have value 'multipart/form-data; boundary=----xxxx' but was 'multipart/form-data; boundary=--------------------------279702090645891265456368' 1) expected 'multipart/form-data;boundary=----xxxx' body but was 'multipart/form-data;boundary=--------------------------279702090645891265456368'
Thank you for any response on this, highly appreciated! If you would like me to, I could open an issue with the pact-js GitHub repository on this topic.
Hope ya'll have a lovely weekend, MartinSyam K
04/29/2023, 8:31 AMconsole.error
Error: Error: read ECONNRESET
at Object.dispatchError (.....\node_modules\jsdom\lib\jsdom\living\xhr-utils.js:54:19)
at Request.<anonymous> (....\node_modules\jsdom\lib\jsdom\living\xmlhttprequest.js:675:20)
at Request.emit (node:events:539:35)
at Request.onRequestError (........\node_modules\request\request.js:877:8)
at ClientRequest.emit (node:events:527:28)
at Socket.socketErrorListener (node:_http_client:454:9)
at Socket.emit (node:events:527:28)
at emitErrorNT (node:internal/streams/destroy:151:8)
at emitErrorCloseNT (node:internal/streams/destroy:116:3)
at processTicksAndRejections (node:internal/process/task_queues:82:21) undefined
at VirtualConsole.<anonymous> (node_modules/jsdom/lib/jsdom/virtual-console.js:29:45)
at Object.dispatchError (node_modules/jsdom/lib/jsdom/living/xhr-utils.js:57:53)
at Request.<anonymous> (node_modules/jsdom/lib/jsdom/living/xmlhttprequest.js:675:20)
at Request.onRequestError (node_modules/request/request.js:877:8)
Syam K
04/29/2023, 8:31 AMit("returns the requested employee", async () => {
provider
.given("I have an empoyee")
.uponReceiving("a request for getting the employee by name")
.withRequest({
method: "GET",
path: "/api/employees/name/Charles",
headers: { Accept: "application/json" },
})
.willRespondWith({
status: 200,
headers: { "content-type": "application/json" },
body: GET_EMPLOYEE_BY_NAME_EXPECTED_BODY,
});
return provider.executeTest(async (mockserver) => {
const employeeService = new EmployeeService(mockserver.url);
const response = await employeeService.getEmployeeByName("John");
expect(await response.headers["content-type"]).toEqual(
"application/json"
);
expect(await response.data).toEqual(GET_EMPLOYEE_BY_NAME_EXPECTED_BODY);
expect(await response.status).toEqual(200);
});
});
Tam Norris
05/01/2023, 6:08 PMAnurag Soni
05/02/2023, 1:12 AMnpm i @pact-foundation/pact
Tien Vo
05/02/2023, 5:02 AMfromProviderState
be flexible about matcher's type?
Currently if I want to use regex
matcher with ProviderState
generator, I have to define a custom method like this:
export function regexFromProviderState(
expression: string,
regex: string,
exampleValue: string
) {
return {
'pact:matcher:type': 'regex',
'pact:generator:type': 'ProviderState',
expression,
value: exampleValue,
regex
};
}
I think it will be the same with other matchers.Damola
05/02/2023, 7:34 AM"method": "GET",
"path": "/v1/assignments",
"query": {
"audienceId": [
"63f57d805d8ecbf46f5b5278"
]
}
Is this normal or can my query appear without being encased in an array?Noor Hashem
05/03/2023, 6:13 PM"pact_foundation_greet/pact": "^9.18.1"
and have a response in the body that can be either a string or null, is anyone aware how can I assert more than one type like a string and/or null using matchers?Michal KopĹiva
05/04/2023, 11:11 AMSvetoldo44ka
05/05/2023, 3:49 PMPravesh
05/11/2023, 2:06 AM"pact:publish": "pact-broker publish ./pacts --consumer-app-version=\"$(npx @pact-foundation/absolute-version)\" --auto-detect-version-properties --broker-base-url=<http://localhost:8000> --broker-username pact_workshop --broker-password pact_workshop"
to package.json in consumer and again executed the test
but when i tried to publish by using command
npm run pact:publish --prefix consumer
but getting below error
npm WARN deprecated @pact-foundation/absolute-version@0.0.4: Package @pact-foundation/absolute-version has been renamed absolute-version. Please install absolute-version instead
{"errors":{"pacticipantVersionNumber":["pacticipantVersionNumber cannot contain multiple lines"]}}
any solution to overcome this?
``` ```Mohit Krishna
05/18/2023, 1:37 PMMohit Krishna
05/18/2023, 1:39 PM