@AdrienMerat,
My first reaction is don’t use the pycontrib lib for Jira. While I greatly appreciate that people invest their own time and energy into open source contribution, I hear about a lot of problems using that library. The last time I looked (just a few days ago, it looked like that library made a lot of strange assumptions that would confound sane unit testing, like needing to GET a Jira issue before allowing a PUT. As I recommended then (and cross-posting and elaborating here for further discussion), if you have any choice in the matter, I would abandon this hand-coded library.
My recommendation would be to use Uplink instead. I prefer this library because it keeps coupling to an absolute minimum: you only “bind” your code to the API endpoints that you need. That keeps you from having to worry that a change in the GET endpoint would affect the PUT. More importantly, Uplink has more robust capabilities for error handling, retries, and rate limiting. From the perspective of unit testing, I think Uplink would help keep the mocking more manageable because the return types are simple.
Another approach that I’ve used is to generate an SDK from the Open API spec using openapi-python-client. You can expect a few generation-time warnings, and the Python linter has a complaint here and there, but it basically works as expected. This is more like the SDK you have, in that it would provide a full type model and code completion. The advantage is the generated SDK is definitionally complete, whereas the hand-coded one in pycontribs is quite limiting. The downside is the high coupling (to everything in the API) and, because the Jira API is so “wide”, the code completion might be noisy (too many options) and slow. From a mocking perspective, this would have all the same headache as the pycontribs library.
In both cases, the tricky, Jira-specific stuff that aren’t in those general libraries are the base URL construction (like https://api.atlassian.com/ex/jira/396b747a-789f-48ec-a637-d0caefeac0ee), and Atlassian’s sometimes quirky OAuth.
You could potentially mock the REST APIs. I built an SDK once using a “monkey patching” HTTP mock like responses. Or you could probably use a full Open API fake server (not in Python). But, ultimately, I think I agree with @sunnyape’s “Don’t bother”. I just have different reasons: from experience, the most “testworthy” parts of a Jira client really in the client code. They are in the endless configuration and corner-case error handling. In testing terms, it’s the “arrange” and the “assert” parts of the “arrange, act, assert” pattern. Your code is unlikely to have sufficient complexity that unit testing will help you find or fix bugs.
You can’t run Jira Cloud as a standalone, locally hosted instance the way you can with the Data Centre version.