Mock Jira API for Jira Python Library


I am building a Python service which needs to interact with my company’s Jira (on cloud). To do that I use the official Jira library for Python (latest version). However when it comes to write unit tests for my service, I don’t know how to mock the Jira API used by the library.

I tried creating a mock Jira class that implements the few methods I use but the problem is that the library doesn’t return native PYthon objects but always customs types (Sequence, Issue, ResultList … etc.) without clean initializations, so if I need to Mock all of theses types it’s gonna make my test bulky and error-prone.

I then think about creating a mock server that handle the API calls made by the library but I don’t know what exact calls are made and that would force me to handle a lot of things making tests also error-prone just by implementing this server.

Finally I thought about running a local Jira instance (in a container) but this is too heavy to be practical.

Is there any practical way to mock the Jira API or library for units tests ? How do people using Jira API usually do to test their service/software ?


Hello @AdrienMerat

If that’s the Atlassian Python lib, it’s not actually developed by Atlassian, it’s a public library. It was written for Jira SERVER and calls only v2 endpoints. It’s getting old now and has many problems with Jira CLOUD, especially the v3 endpoints, so you need to very seriously consider not becoming dependant on it and use the native Python Requests library instead.

Not only impractical, but impossible :slight_smile: You can’t run Jira Cloud as a standalone, locally hosted instance the way you can with the Data Centre version.

Don’t bother because you don’t need to. Just make your test calls directly to the live instance. If you need to, create a dummy project where you can run amok without disturbing others. If you intend to interact with the more delicate or valuable parts, your company can liaise with Atlassian and arrange for a development instance of their cloud environment.

Have fun.



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, 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.


Thanks for the details. However I read on the Jira REST API website that V3 is still in beta so that may explain why it’s still unsupported by the Python library. I think I’ll indeed switch to Python requests but I feel sad to have this Jira library that is so unpractical.

Thanks for the response. I won’t go with Uplink as it’s still beta and I want to get my dependencies as limited as possible so as requests can do the job it’s fine.