rholshausen
commented
2 months ago There is no spec for what the --state-change-url will send. You can find the answer in the pact_verifier source code, but this should really be more easily accessible in the documentation itself.
Updated the README for this.
It isn't immediately clear what form --state-change-url needs to take. Is it the full URL, or can you use a relative path? If the latter, will --base-path be honoured? (the source code is harder to follow here, but it looks like the URL needs to be absolute).
It is an absolute path. Updated the README.
It is unclear what path on the provider would be used to POST asynchronous messages to for testing. Is this the --base-path perhaps? If so, that would make it very hard to test both async message contracts and HTTP request-response contracts in the same verification session if a provider already has a API root POST endpoint used for other purposes.
If both HTTP and message interactions are defined in the same Pact, the verifications for these can be configured using the --transports <transports> option. For example, --transports http:8080 message:8081 will send HTTP requests to port 8080 and message requests to port 8081. I'll update the README to document this.
YOU54F
I find myself referring to the verifier source code to figure out what the different CLI options do:
--state-change-urlwill send. You can find the answer in the pact_verifier source code, but this should really be more easily accessible in the documentation itself.--state-change-urlneeds to take. Is it the full URL, or can you use a relative path? If the latter, will--base-pathbe honoured? (the source code is harder to follow here, but it looks like the URL needs to be absolute).--base-pathperhaps? If so, that would make it very hard to test both async message contracts and HTTP request-response contracts in the same verification session if a provider already has a API root POST endpoint used for other purposes.Perhaps a more fully-featured example, including a sample could be provided?