<p dir="ltr"><br>
On 22 Feb 2016 9:23 PM, "Sandro Santilli" <<a href="mailto:strk@keybit.net">strk@keybit.net</a>> wrote:<br>
><br>
> On Fri, Feb 19, 2016 at 09:53:29AM +1100, Nyall Dawson wrote:<br>
> > On 17 February 2016 at 21:32, Neumann, Andreas <<a href="mailto:a.neumann@carto.net">a.neumann@carto.net</a>> wrote:<br>
> > ><br>
> > > As you may remember, Strk participated in the paid bug fixing program. He<br>
> > > made some comments which I am forwarding to the board:<br>
> > ><br>
> > > --------------------------- Citing -------------------------------<br>
> > ><br>
> > > This bugfixing drive convinced me even more that QGIS needs to improve its<br>
> > > testsuite framework: it was often difficult to figure out how to provide a<br>
> > > test for a bug, there was no provision to write a test before fixing a bug<br>
> > > (useful to prove the fix is needed), there is only python testing for the<br>
> > > whole PostgreSQL provider and it is not automatically setup to run. Shall<br>
> > > there be a budget to improve the situation, please let me know as I have a<br>
> > > few ideas.<br>
> > ><br>
> > > ------------------------------------------------------------------<br>
> ><br>
> > To be honest, I'm actually of the opposite view. I think QGIS' test<br>
> > suite infrastructure is becoming quite mature and reliable.<br>
><br>
> I would not call this an "opposite view". I didn't say it become worst<br>
> or didn't improve (it did, a lot!). Only I think it should keep improving.</p>
<p dir="ltr">100% agree! It makes me so happy to see how rapidly the test suite covering is growing.</p>
<p dir="ltr">><br>
> > For python tests you can mark them as expected failures with<br>
> ><br>
> > @unittest.expectedFailure (see<br>
> > <a href="https://docs.python.org/2/library/unittest.html#unittest.expectedFailure">https://docs.python.org/2/library/unittest.html#unittest.expectedFailure</a>)<br>
><br>
> It's not clear from the documentation if an unexpected success counts<br>
> as a failure. That's what I'm after, so that a fix is immediately<br>
> secured in a test rather than left as a discarded test.</p>
<p dir="ltr">It throws a warning, but that's it. It's hard to find proof, but <a href="https://code.djangoproject.com/ticket/23943">https://code.djangoproject.com/ticket/23943</a> seems to suggest that this will cause a failure in Python 3.0. Not sure.</p>
<p dir="ltr">><br>
> > For c++ tests I'd "#ifdef 0" until they are fixed.<br>
><br>
> Same as above, it won't help noticing that a test does exist.</p>
<p dir="ltr">Sorry, bad advice. Looking into this the correct approach is to use the QEXPECT_FAIL macro:</p>
<p dir="ltr"><a href="http://doc.qt.io/qt-4.8/qtest.html#QEXPECT_FAIL">http://doc.qt.io/qt-4.8/qtest.html#QEXPECT_FAIL</a></p>
<p dir="ltr">I don't recall seeing anyone put this to use in QGIS yet, but we should do so where appropriate.</p>
<p dir="ltr">Nyall</p>
<p dir="ltr">><br>
> > > there is only python testing for the<br>
> > > whole PostgreSQL provider and it is not automatically setup to run.<br>
> ><br>
> > I personally don't think this is an issue. Not everyone has access to<br>
> > a PostGIS setup for this test to run with, and even if they do they<br>
> > may not want running the QGIS test suite to automatically create and<br>
> > modify tables on their setup (eg, I would not be happy if the test was<br>
> > modifying my production database!!)<br>
><br>
> The qgis testsuite is using a "qgis_test" database for tests.<br>
> Sounds like a safe default. It could be made even safer if you think<br>
> it is needed.<br>
><br>
> Whether or not PostGIS setup is available could be spotted at source<br>
> configuration time.<br>
><br>
> > Again, better test docs would help here.<br>
><br>
> Surely docs would be an improvement.<br>
><br>
> > So in summary - I actually think the current test suite setup is good<br>
> > (and getting constantly better), and the main problem is both lack of<br>
> > testing documentation and training QGIS developers in how to utilise<br>
> > it. I'd be happy to run a session during the hackfest explaining all<br>
> > this, if that's considered worthwhile...<br>
><br>
> I'll be there, if available on IRC :)<br>
><br>
> --strk;<br>
</p>