<div dir="auto">Agreed about test interdependency being rough. Internally at work, we have a test runner that intentionally does not run tests in order.  All the autotest2 stuff I did should all be order independent.  Sadly, my old tests are using pythons normal test setup, not pytest.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Feb 20, 2023, 7:57 AM Daniel Evans <<a href="mailto:daniel.fred.evans@gmail.com">daniel.fred.evans@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> Additionally, these loops fix the order that the checks are made, and bugs can hide in test order dependency.<br>
<br>
As we're on the topic of pytest, I'll mention fixtures as a handy<br>
feature for test setup: <a href="https://docs.pytest.org/en/6.2.x/fixture.html" rel="noreferrer noreferrer" target="_blank">https://docs.pytest.org/en/6.2.x/fixture.html</a><br>
<br>
I discovered a while back that some parts of the GDAL test suite break<br>
if test order changes, because Test B relies implicitly some state<br>
being left over from Test A. This prevents some possible improvements<br>
like parallelising the test suite for speed (at least, without careful<br>
manual organisation of what can be done in parallel). It was also a<br>
little annoying trying to debug tests that started segfaulting when<br>
the order changed!<br>
<br>
Regards,<br>
Daniel<br>
<br>
On Mon, 20 Feb 2023 at 15:43, Sean Gillies <<a href="mailto:sean.gillies@gmail.com" target="_blank" rel="noreferrer">sean.gillies@gmail.com</a>> wrote:<br>
><br>
> Hi all,<br>
><br>
> I just saw a maintainer recommend to a contributor that the contributor loop over test cases from within a test function and it prompted me to speak up about a better practice: using pytest parameterization <a href="https://docs.pytest.org/en/6.2.x/parametrize.html#pytest-mark-parametrize-parametrizing-test-functions" rel="noreferrer noreferrer" target="_blank">https://docs.pytest.org/en/6.2.x/parametrize.html#pytest-mark-parametrize-parametrizing-test-functions</a>.<br>
><br>
> Using a loop, like at <a href="https://github.com/OSGeo/gdal/blob/master/autotest/gcore/gdal_stats.py#L660" rel="noreferrer noreferrer" target="_blank">https://github.com/OSGeo/gdal/blob/master/autotest/gcore/gdal_stats.py#L660</a>, can hide bugs and add friction to development. In that particular case, there are 5 different fill values to be checked. If there are different code paths for each of these values (a worst case scenario) and each has a small bug, you will have to run the whole test suite 5 times to expose the 5 bugs one at a time. Additionally, these loops fix the order that the checks are made, and bugs can hide in test order dependency. Ideally, GDAL's tests run in random order.<br>
><br>
> In a nutshell, you hoist the loop and list out into a test function decorator and then pytest discovers and runs all the separate cases. Pytest doesn't stop on the first failure in the list unless you explicitly tell it to do so.<br>
><br>
> # Original GDAL test code<br>
> def test_fill_value():<br>
>     for fill_val in [0, 1, 32767, 32768, 65535]:<br>
>         func(fill_val)<br>
>         assert something<br>
><br>
> # With pytest parameterization<br>
> @pytest.mark.parametrize("fill_val", [0, 1, 32767, 32768, 65535])<br>
> def test_fill_value(fill_val):<br>
>         func(fill_val)<br>
>         assert something<br>
><br>
> I'm not proposing rewrites of old tests, but I think it is worth adopting a better practice for tests now and in the future.<br>
><br>
> --<br>
> Sean Gillies<br>
> _______________________________________________<br>
> gdal-dev mailing list<br>
> <a href="mailto:gdal-dev@lists.osgeo.org" target="_blank" rel="noreferrer">gdal-dev@lists.osgeo.org</a><br>
> <a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev" rel="noreferrer noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
_______________________________________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank" rel="noreferrer">gdal-dev@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev" rel="noreferrer noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
</blockquote></div>