<div dir="ltr"><div class="gmail_default" style="font-family:georgia,serif">Hi</div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 18, 2014 at 4:52 PM, Matthias Kuhn <span dir="ltr"><<a href="mailto:matthias.kuhn@gmx.ch" target="_blank">matthias.kuhn@gmx.ch</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
You may have noticed that there is a new symbol on the qgis github page<br>
that (hopefully) says build passing. [1]<br>
<br>
The last week I have been busy with fixing tests for integration with<br>
Travis CI.<br>
<br>
Right now, whenever somebody pushes a change to<br>
 * a branch in the qgis repository (that affects "master" and<br>
release-x_y branches)<br>
 * a pull request for the qgis repository<br>
a service called Travis CI [2] will be activated and compile the<br>
sourcecode and run the test suite there. That has the advantage that we<br>
have a reference platform (ubuntu precise for the moment) where all<br>
tests pass. This defined environment is a big step forward as it makes<br>
test runs comparable and if something goes wrong we know that code is<br>
responsible and not some other variable.<br>
Currently all tests (with a few exceptions which are disabled) are<br>
passing. And it would be excellent if it stays like that!<br>
<br>
What does that mean for developers?<br>
<br>
**Use pull requests**<br>
Whenever you open a pull request first you get the chance to test your<br>
changes without making the nice green symbol on the front page go red.<br>
You can push to these pull requests until the tests go green. For<br>
reviewers this is also nice: you don't need to spend time on pull<br>
requests that don't build or don't pass tests.<br>
<br>
**Write tests**<br>
If you implement a new feature or fix a bug, write a test for it. If<br>
somebody breaks the test, the pull request or the symbol on the github<br>
project page will turn red. This means that it's clear which commit<br>
broke the test. But the test is your feature or your bugfix!<br>
<br>
**Try to avoid rendering tests**<br>
A big portion of fixing has been spent on rendering tests. The problem<br>
with rendering tests is, that a lot of them have slight inconsistencies<br>
across systems. Gradients, anti aliasing, fonts... This all may render<br>
differently without being really a problem. But it produces a (false)<br>
alarm on another system and one needs to take measures. There are such<br>
measures: defining color intolerance, allowed pixel mismatches, known<br>
anomalies, since last week also different reference pictures... But in<br>
the end this means extra work and false alarms once in a while. We do<br>
create a software that has visual products. Therefore rendering tests<br>
are required. But think very about different possibilities before<br>
writing such a test. Maybe you can extract the WKT from a geometry and<br>
compare that against a known WKT string instead? That is less brittle,<br>
faster to test and much easier to maintain than a rendering test!<br>
If you really need to write a rendering test it is likely that it will<br>
fail on travis in the beginning. To make it pass on travis, create a<br>
pull request and wait for it to be tested. The results will be uploaded<br>
to the OTB CDash [3] where you get information what exactly you need to<br>
adjust. How many pixels failed? Visual comparison if adjusting the color<br>
tolerance a bit may help. Is an anomaly ok? Is there a need to add<br>
another reference picture?<br>
<br>
**C++ vs. Python tests**<br>
I made an earlier call for having only either one or the other. That was<br>
based on misinterpretation of test results from my side. Sorry.<br>
My current opinion is: do what you feel comfortable with. If you prefer<br>
to write C++ tests, do so. If you prefer to write Python tests, do so.<br>
If you want both, do so. The important thing is: DO IT!<br>
If you really need advice: go for python tests, they test the same<br>
functionality like C++ functions but also test the python API and<br>
therefore cover a slightly bigger area.<br>
<br>
Which tests are not fixed (on the reference platform)?<br>
<br>
 * The atlas tests had interdependencies, that made some tests pass just<br>
because the environment was ok from previous ones. These tests are now<br>
changed to be independent one of another. And there is a PR that should<br>
fix the issues and re-enable the test. [4]<br>
 * The symbology tests fail due to problems with sld loading. There is a<br>
pull request that partly reverts a commit that broke things and<br>
re-enables the test. [5]<br>
 * The server pal labeling tests produced very different rendering<br>
results. I could imagine that they would be better off if the would also<br>
use the QGIS test font? New reference images could also be introduced.<br>
Dakota cartography's call.<br>
 * The server canvas labeling tests crash on exit because of a<br>
not-yet-ended thread. Multithreading issue? Something else?<br>
 * Recently the WCS test started to fail. I guess the server it uses to<br>
test does not always respond? We should either fix the server, disable<br>
the test, increase the timeout...<br>
<br>
Where to go from here?<br>
<br>
There are two things I would like to see:<br>
<br>
  Many more tests :)<br>
  More platforms: Travis can also handle mac. We could ask them to<br>
enable mac testing for us. But we'd first need to fix the tests there.<br>
There is a service called appveyor that runs tests for windows. But we'd<br>
first need to fix the tests there.<br>
<br>
I am very happy that there was such a great interest in the crowdfunding<br>
campaign that made it possible to do that work. THANK YOU to everybody<br>
who helped to get the testing integration to the next level.<br>
<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:georgia,serif">​Brilliant stuff Matthias! Now we need to agree to 'no new code without tests' as a formal requirement and we will be a long way down the road towards a more stable QGIS.</div><div class="gmail_default" style="font-family:georgia,serif"><br></div><div class="gmail_default" style="font-family:georgia,serif">Regards</div><div class="gmail_default" style="font-family:georgia,serif"><br></div><div class="gmail_default" style="font-family:georgia,serif">Tim​</div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Matthias<br>
<br>
[1] <a href="https://github.com/qgis/QGIS" target="_blank">https://github.com/qgis/QGIS</a><br>
[2] <a href="http://travis-ci.org/" target="_blank">http://travis-ci.org/</a><br>
[3] <a href="http://dash.orfeo-toolbox.org/index.php?project=QGIS" target="_blank">http://dash.orfeo-toolbox.org/index.php?project=QGIS</a><br>
<br>
_______________________________________________<br>
Qgis-developer mailing list<br>
<a href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div style="text-align:center">------------------------------------------------------------------------------------------</div><div style="text-align:center"><img src="http://kartoza.com/wp-content/uploads/2014/06/KartozaWebBanner.png" width="200" height="40"></div><div style="text-align:center">Tim Sutton</div><div style="text-align:center"><span style="text-align:start">Visit </span><a href="http://kartoza.com/" style="text-align:start" target="_blank">http://kartoza.com</a><span style="text-align:start"> to find out about open source:</span><br style="text-align:start"><span style="text-align:start"> * Desktop GIS programming services</span><br style="text-align:start"><span style="text-align:start"> * Geospatial web development</span></div><div style="text-align:center"><span style="text-align:start">* GIS Training</span></div><div style="text-align:center"><span style="text-align:start">* Consulting Services</span></div><div style="text-align:center"><div style="text-align:center">Skype: timlinux Irc: timlinux on #qgis at <a href="http://freenode.net/" target="_blank">freenode.net</a></div><div style="text-align:start"><div style="text-align:center">Tim is a member of the QGIS Project Steering Committee</div><div style="text-align:center">-------------------------------------------------------------------------------------------</div><div style="text-align:center">Kartoza is a merger between Linfiniti and Afrispatial</div></div></div></div></div>
</div></div>