[QGIS-Developer] Travis failing in QGIS-Documentation

Alessandro Pasotti apasotti at gmail.com
Tue Jan 12 03:46:31 PST 2021


On Tue, Jan 12, 2021 at 12:38 PM Richard Duivenvoorde
<rdmailings at duif.net> wrote:
>
> On 1/12/21 12:32 PM, Alessandro Pasotti wrote:
> > On Tue, Jan 12, 2021 at 11:51 AM Richard Duivenvoorde
> >> but... one of my docs (temporal navigator) PR's is still failing:
> >> https://travis-ci.org/github/qgis/QGIS-Documentation/builds/739861175
> >>
> >> NOT image related, but if somebody finds some time to check, please let me know what I'm doing wrong.
> >>
>
> > I think this is None:
> > navigator = iface.mapCanvas().temporalController()
> >
> > I wonder if it would be better to use a full real QGIS for doc
> > testing, the same system we use for plugins testing as explained here:
> > https://github.com/qgis/QGIS/tree/master/.docker#running-unit-tests-inside-qgis
>
> I thought we did that?
> https://github.com/qgis/QGIS-Documentation/blob/release_3.16/doctest.dockerfile
> don't we use that docker to have a 'real' QGIS?

We do, but we are running doctests using python directly, not invoking
QGIS and running the tests inside it.

To elaborate what a "real QGIS" means in this context there are (at
least) two ways of running tests:

1. the way we use for all Travis CI tests in core: run the tests
directly from python using a mocked QgsApplication and iface, in this
case we are using the "real QGIS" libraries but not the "real QGIS
application"
2. the way I originally developed for Python plugins CI in Boudless
(I'm not using that personally anymore) which was to run Python tests
**inside** a "real QGIS" application.

The advantage of (2) is that there is no need to mock anything, the
tests are run as if you were inside QGIS and using the QGIS Python
console.

The disadvantage is that it is slower.

-- 
Alessandro Pasotti
QCooperative:  www.qcooperative.net
ItOpen:   www.itopen.it


More information about the QGIS-Developer mailing list