feat: pact contract for get job by id and post job - #106
duvanmoionq wants to merge 5 commits into
Conversation
|
Thank you @duvanmoionq! before a full review, a question: should the new tests be added to the CI too? or does |
Yes! we would do that later for now we are only adding test contracts examples that we can follow to add more contracts. we will add later the CI logic whenever we configure the Broker we need. |
antalszava
left a comment
antalszava
left a comment
There was a problem hiding this comment.
Thank you so much @duvanmoionq! 👏 Very interesting direction.
I've left a couple of comments, my main feedback is: could we somehow dynamically depend on the API spec that we have in the repo in the pact?
Also, could you further describe what we gain from using pact instead of "simply" writing pytest tests with expected responses?
| @@ -0,0 +1,165 @@ | |||
| """Pact HTTP contract: ionq-core-python (consumer) -> cloud-job-manager (provider). | |||
There was a problem hiding this comment.
Is it a convention to have a consumers folder inside the pact folder?
First it seems a bit unnecessary to have two levels of folder nesting atm.
There was a problem hiding this comment.
Yes that's the convention we decided to follow in all the repos.
| """Pact HTTP contract: ionq-core-python (consumer) -> cloud-job-manager (provider). | ||
|
|
||
| Pins the two jobs-API interactions the SDK depends on, in ONE pact | ||
| (ionq-core-python-cloud-job-manager.json): |
There was a problem hiding this comment.
The mention of ionq-core-python-cloud-job-manager.json seems a bit confusing here since it's not a file in the repo - where does it live?
There was a problem hiding this comment.
I removed that comment but I will keep cloud-job-manager-http because that's the name of the provider.
| Pins the two jobs-API interactions the SDK depends on, in ONE pact | ||
| (ionq-core-python-cloud-job-manager.json): | ||
|
|
||
| 1. POST /v0.4/jobs create a circuit job -> 201 {id, status, session_id} |
There was a problem hiding this comment.
This endpoint can have different inputs: single-circuit,multi-circuit, quantum function and qaoa function. Should that matter here/does that matter for the contract?
There was a problem hiding this comment.
Yes that's very true. and that's the idea! so we can add contracts to cover all cases. but for now the idea of this PR is just to add an example, structure to follow.
| 1. POST /v0.4/jobs create a circuit job -> 201 {id, status, session_id} | ||
| 2. GET /v0.4/jobs/{id} fetch a completed job -> 200 (every SingleCircuitJob |
There was a problem hiding this comment.
Imho these should be coming dynamically from this repo's API spec version. Accordingly, I think it would be good to remove/keep the endpoint and payload descriptions minimal here because they need to be changed here each time their spec changes.
| PACT_DIR.mkdir(exist_ok=True) | ||
| pact.write_file(PACT_DIR, overwrite=True) |
There was a problem hiding this comment.
What do these instructions do?
There was a problem hiding this comment.
They create the consumer contract file(pacts/ionq-core-python-cloud-job-manager.json) that is published to the pact broker.
About dynamically depending on the API spec, I am no sure I follow what you mean, what do you have in mind? |
2 participants
QTPF-9072
install pact dependency
Adding pact contract for http POST /job
Adding pact contract for http GEt /job/{id}