[QGIS-Developer] Experience with coverage.py?

[Rizky Maulana Nugraha]

Hi Sebastian,

In the past, I co-developed this repo: https://github.com/inasafe/inasafe-headless and mainly involved with the testing architecture. It is a legacy code which we haven’t maintain for quite some time and haven’t been migrated to python 3/ QGIS 3. But I imagine the concept is similar.

I’m going to share you some information about the repo, so you can determine if the use case is similar. The repositories has the following characteristic:


• It tests a python application, that uses functions from a QGIS plugin (python code), that is running headlessly, on top of headless QGIS, on top of docker container
• The code heavily uses horizontal scaling and threading via Python Celery module. But since mainly the purpose is to generate reports, it is best to run it as single threaded app and the scaling is done by horizontally increase the scale of worker containers (not Linux process inside a container)
• There are two main part of the codes the master node and worker node. Worker node will always run in a different thread from master node. So the coverage.py scripts needs to be “injected” in the python’s “sitecustomize.py” file in it’s dist dir.
• You can not generate one coverage report in this scenario, since part of the code runs in different contexts. Leverage coverage.py to gather multiple reports from different process, and aggregate the report.
• Bug that happens usually caused by race condition due to the constraint that there should be one running UI thread and you need to properly switch the context. All the resources also needs to be carefully deallocated if you deal with UI (in my case, the QgsComposer functionality).


I’ve managed to do this in QGIS 2, so it is not impossible :).
If you have race condition, there are two possible cause:

1. You didn’t respect the threading constraint (background tasks should not update UI tasks directly)
2. The functionality you use, simply doesn’t support multi threading or not designed to be multi threading

When I encounter case 2, my workaround is to not go against it, but rather horizontally scale in container contexts, instead of native threads. But this might not apply in your case. It depends on how you are planning to use multithreading in your app.

You can directly check how we test it by navigating into the .travis.yml file to see how the architecture is built and used.

Regards,
--
Rizky Maulana Nugraha
Senior Software Engineer
Kartoza
rizky at kartoza.com
On 14 Apr 2020 21.50 +0700, Sebastian M. Ernst <ernst at pleiszenburg.de>, wrote:
> Hi all,
>
> has someone by any chance been trying or even successfully using
> `coverage.py` (1) inside QGIS' Python code and/or plugins and could
> share some experience?
>
> For me, it works, sometimes, with plenty of edge cases ... I am
> basically running into all sorts of wired issues - presumably due to
> threads and race conditions.
>
> Thanks,
> Sebastian
>
>
> 1: https://coverage.readthedocs.io/
> _______________________________________________
> QGIS-Developer mailing list
> QGIS-Developer at lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20200415/c53baa10/attachment.html>