<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Abel,<br>
</p>
<div class="moz-cite-prefix">Le 09/02/2024 à 10:55, Abel Pau via
gdal-dev a écrit :<br>
</div>
<blockquote type="cite"
cite="mid:AS8PR07MB7766B7BD8750D12E3D01EC53A24B2@AS8PR07MB7766.eurprd07.prod.outlook.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta name="Generator"
content="Microsoft Word 15 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]-->
<style>@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;
mso-fareast-language:EN-US;}a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0cm;
margin-right:0cm;
margin-bottom:0cm;
margin-left:36.0pt;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;
mso-fareast-language:EN-US;}span.EstiloCorreo17
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;
mso-fareast-language:EN-US;}div.WordSection1
{page:WordSection1;}ol
{margin-bottom:0cm;}ul
{margin-bottom:0cm;}</style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<p class="MsoNormal"><span lang="EN-US">Hi,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">I am at the lasts steps
before pulling a request about the MiraMon driver.
<br>
I need to write some documentation and formalize the tests.
<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">After that, I’ll do the
pull request to github.</span></p>
</div>
</blockquote>
I'd suggest first before issuing the pull request that you push to
your fork on github and look at the Actions tab. That will allow you
to fix a lot of things on your side, before issuing the PR itself<br>
<blockquote type="cite"
cite="mid:AS8PR07MB7766B7BD8750D12E3D01EC53A24B2@AS8PR07MB7766.eurprd07.prod.outlook.com">
<div class="WordSection1">
<p class="MsoNormal"><span lang="EN-US"><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">I am a little confused
about the testing. I can use pytest or ctest, right? Which
is the favourite? Are there any changes from the official
documentation?</span></p>
</div>
</blockquote>
<p>ctest is just the CMake way of launching the test suite. It will
execute C++ tests of autotest/cpp directly, and for tests written
in python will launch "pytest autotest/XXXXX" for each directory.
<br>
</p>
<p>"ctest --test-dir $build_dir -R autotest_ogr -V" will just run
all the autotest/ogr tests, which can be quite long already.<br>
</p>
<p>To test your own development, you may have a more pleasant
experience by directly running just the tests for your driver with
something like "pytest autotest/ogr/ogr_miramon.py" (be careful
on Windows, the content of $build_dir/autotest is copied from
$source_dir/autotest each time "cmake" is run, so if you edit your
test .py file directly in the build directory, be super careful of
not accidentally losing your work, and make sure to copy its
content to the source directory first. That's admittedly an
annoying point of the current test setup on Windows, compared to
Unix where we use symbolic links)<br>
</p>
<p>after setting the environment to have PYTHONPATH point to
something like $build_dir/swig/python/Release or
$build_dir/swig/python/Debug (I believe you're on Windows?). If
you look at the first lines output by the above "ctest --test-dir
$build_dir -R autotest_ogr -V" invokation, you'll actually see the
PYTHONPATH value to specify.</p>
<p>You also need to first install pytest and other testing
dependencies with: python -m pip install autotest/requirements.txt<br>
</p>
<blockquote type="cite"
cite="mid:AS8PR07MB7766B7BD8750D12E3D01EC53A24B2@AS8PR07MB7766.eurprd07.prod.outlook.com">
<div class="WordSection1">
<p class="MsoNormal"><span lang="EN-US"><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">There is a minimal test
to create?</span></p>
</div>
</blockquote>
A maximal test suite, you mean ;-) You should aim for a "reasonable"
coverage of the code you wrote. Aiming to test the nominal code
paths of your driver is desirable (testing the error cases generally
requires a lot more effort). <br>
<blockquote type="cite"
cite="mid:AS8PR07MB7766B7BD8750D12E3D01EC53A24B2@AS8PR07MB7766.eurprd07.prod.outlook.com">
<div class="WordSection1">
<p class="MsoNormal"><span lang="EN-US"><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">Can you recommend me
some driver that tests things like:<o:p></o:p></span></p>
<p class="MsoListParagraph"
style="text-indent:-18.0pt;mso-list:l0 level1 lfo1"><!--[if !supportLists]--><span
style="font-family:Symbol" lang="EN-US"><span
style="mso-list:Ignore">·<span
style="font:7.0pt "Times New Roman"">
</span></span></span><!--[endif]--><span lang="EN-US">Read
a point/arc/polygon layer from some format (gml,kml,
gpckg,..) and assert the number of readed objectes<o:p></o:p></span></p>
<p class="MsoListParagraph"
style="text-indent:-18.0pt;mso-list:l0 level1 lfo1"><!--[if !supportLists]--><span
style="font-family:Symbol" lang="EN-US"><span
style="mso-list:Ignore">·<span
style="font:7.0pt "Times New Roman"">
</span></span></span><!--[endif]--><span lang="EN-US">Read
a point layer and assert some points (3d included) and some
of the fields values<o:p></o:p></span></p>
<p class="MsoListParagraph"
style="text-indent:-18.0pt;mso-list:l0 level1 lfo1"><!--[if !supportLists]--><span
style="font-family:Symbol" lang="EN-US"><span
style="mso-list:Ignore">·<span
style="font:7.0pt "Times New Roman"">
</span></span></span><!--[endif]--><span lang="EN-US">The
same with arcs and polygons<o:p></o:p></span></p>
<p class="MsoListParagraph"
style="text-indent:-18.0pt;mso-list:l0 level1 lfo1"><!--[if !supportLists]--><span
style="font-family:Symbol" lang="EN-US"><span
style="mso-list:Ignore">·<span
style="font:7.0pt "Times New Roman"">
</span></span></span><!--[endif]--><span lang="EN-US">Create
some layer from the own format to anothers and compare the
results with some “good” results.<o:p></o:p></span></p>
<p class="MsoListParagraph"
style="text-indent:-18.0pt;mso-list:l0 level1 lfo1"><!--[if !supportLists]--><span
style="font-family:Symbol" lang="EN-US"><span
style="mso-list:Ignore">·<span
style="font:7.0pt "Times New Roman"">
</span></span></span><!--[endif]--><span lang="EN-US">Create
multiple layers from one outer format (like gpx) and verify
the name of the created files...</span></p>
</div>
</blockquote>
<p>You don't necessarily need to use other formats. It is actually
better if the tests of a format don't depend too much on other
formats, to keep things isolated.</p>
<p>To test the read part of your driver, add a
autotest/ogr/data/miramon directory with *small* test files,
ideally at most a few KB each to keep the size of the GDAL
repository reasonable, and a few features in each is often enough
to unit test, with different type of geometries, attributes, and
use the OGR Python API to open the file and iterate over its
layers and features to check their content. Those files should
have ideally be produced by the Miramon software and not by the
writing side of your driver, to check the interoperability of your
driver with a "reference" software.</p>
<p>For the write site of the driver, you can for example run
gdal.VectorTranslate(dest, source) on those files, and use again
the test function to validate that the read side of your driver
likes what the write site has produced. An alternative is also to
do a binary comparison of the file generated by your driver with a
reference test file stored in for example
autotest/ogr/data/miramon/ref_output. But this may be sometimes a
fragile approach if the output of your driver might change in the
future (would require regenerating the reference test files).<br>
</p>
<p>I'd suggest your test suite also has a test that runs the
"test_ogrsf" command line utility which is a kind of compliance
test suite which checks a number of expectations for a driver,
like that GetFeatureCount() returns the same number as iterating
with GetNextFeature(), etc etc<br>
</p>
<p>It is difficult to point at a "reference" test suite, as all
drivers have their particularities and may need specific tests.
Potential sources of inspirations:</p>
<p>- autotest/ogr/ogr_gtfs.py . Shows very simple testing of the
read side of a driver, and includes a test_ogrsf test</p>
<p>- autotest/ogr/ogr_csv.py has examples where the writing side of
the driver is checked by opening the output file and checking that
some strings are present in it (only easily doable with text based
formats)<br>
</p>
<p>- autotest/ogr/ogr_openfilegdb_write.py . Extensive testing of
the writing side of a driver . A lot in it will be specific to the
format and irrelevant to your concern, but you should at least
find all possible aspects of how to test the write side of a
driver.</p>
Even<span style="white-space: pre-wrap">
</span>
<pre class="moz-signature" cols="72">--
<a class="moz-txt-link-freetext" href="http://www.spatialys.com">http://www.spatialys.com</a>
My software is free, but my time generally not.</pre>
</body>
</html>