<div dir="auto">Hi, <div dir="auto"><br></div><div dir="auto">IMHO, choice of testing framework is secondary and focus should indeed be on integration of Kurt's tests into upstream of PROJ, and GDAL and GEOS too. </div><div dir="auto">This is unfortunate situation that such valuable continuous efforts like autotest2 lives outside the upstreams.</div><div dir="auto">It would be pity if this situation clones into PROJ. <br></div><div dir="auto"><br></div><div dir="auto"><br><div data-smartmail="gmail_signature" dir="auto">Mateusz Loskot, <a href="mailto:mateusz@loskot.net">mateusz@loskot.net</a><br>(Sent from mobile) </div></div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, 30 May 2018, 20:36 Kurt Schwehr, <<a href="mailto:schwehr@gmail.com">schwehr@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">So... Just to state my preference. I think Google Test(gtest/gmock/microbenchmark) would be great if PROJ decides to go that way. It's been run through the ringer with hundreds of millions of lines of tests written with it and it covers most use cases without being to heavy weight. And I would be happy to contribute my tests to PROJ (switching them to the PROJ license) and drop them from gdal-autotest2.<div><br></div><div>I really don't know Catch2 so I don't really have an opinion on how well it works.</div><div><br></div><div>Either way, I will keep on doing PROJ/GEOS/GDAL testing in gtest for my own work.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 29, 2018 at 1:57 PM, Mateusz Loskot <span dir="ltr"><<a href="mailto:mateusz@loskot.net" target="_blank" rel="noreferrer">mateusz@loskot.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 29 May 2018 at 22:02, Kristian Evers <<a href="mailto:kreve@sdfe.dk" target="_blank" rel="noreferrer">kreve@sdfe.dk</a>> wrote:<br>
> On 29 May 2018, at 21:14, Mateusz Loskot <<a href="mailto:mateusz@loskot.net" target="_blank" rel="noreferrer">mateusz@loskot.net</a>> wrote:<br>
>> On Tue, 29 May 2018, 20:37 Kristian Evers, <<a href="mailto:kreve@sdfe.dk" target="_blank" rel="noreferrer">kreve@sdfe.dk</a>> wrote:<br>
>>><br>
>>> So in summation my proposed TODO list goes something like:<br>
>>><br>
>>> 1. Move tests from src/ to the Catch2 framework<br>
>>> 2. Move selftest remnants in gie.c to the Catch2 framework<br>
>>> 3. Move shell-script tests in nad/ to test/<br>
>>> 4. Add a test framework for the command line applications, also in<br>
>>> test/<br>
>>><br>
>>> Thoughts? What have I missed?<br>
>><br>
>><br>
>> Although might be to early, but perhaps an outline of tests organization<br>
>> into suites and cases.<br>
>><br>
>> For example:<br>
>><br>
>> - test suite per API function - a sort of unit kind of tests focused on<br>
>> exercising single function (similar tests also could verify definitions of<br>
>> data structures). Eg. Call foo(a, b) with valid, invalid, boundary, random,<br>
>> etc. values for parameters.<br>
>><br>
>> - test suites of more complex test cases, more complex Arrangements<br>
>> preparing for actual test as well as more elaborate assertions following a<br>
>> testing act - I like to think of those as functional tests (function is a<br>
>> black box) or inter-function integration tests :) Eg. Verifying conversion<br>
>> of X from CRS A to B gives expected results, depending on input valid,<br>
>> invalid, boundary…<br>
><br>
</span><span>> Your first point sounds like something we should do at least. We definitely<br>
> need tests for each function in the library. The second point, if I understand<br>
> correctly, is more or less covered by gie tests.<br>
<br>
</span>Yes, I think so.<br>
<br>
Although, there are some cases where such Catch-based functional testing<br>
may be a good idea. For example, verification that pj_init and<br>
pj_init_plus for the<br>
same definition result in equialent instance of projPJ; any kind of verification<br>
of library/object states following interleaved/sequenced API calls;<br>
any kind of round-trips verification with assertions for intermediate results<br>
Such functional tests typically have more assertions per case than unit tests.<br>
<br>
Best regards,<br>
<span class="m_282723628490508715HOEnZb"><font color="#888888">-- <br>
Mateusz Loskot, <a href="http://mateusz.loskot.net" rel="noreferrer noreferrer" target="_blank">http://mateusz.loskot.net</a><br>
</font></span><div class="m_282723628490508715HOEnZb"><div class="m_282723628490508715h5">_______________________________________________<br>
Proj mailing list<br>
<a href="mailto:Proj@lists.maptools.org" target="_blank" rel="noreferrer">Proj@lists.maptools.org</a><br>
<a href="http://lists.maptools.org/mailman/listinfo/proj" rel="noreferrer noreferrer" target="_blank">http://lists.maptools.org/mailman/listinfo/proj</a></div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="m_282723628490508715gmail_signature" data-smartmail="gmail_signature">--<div><a href="http://schwehr.org" target="_blank" rel="noreferrer">http://schwehr.org</a></div></div>
</div>
_______________________________________________<br>
Proj mailing list<br>
<a href="mailto:Proj@lists.maptools.org" target="_blank" rel="noreferrer">Proj@lists.maptools.org</a><br>
<a href="http://lists.maptools.org/mailman/listinfo/proj" rel="noreferrer noreferrer" target="_blank">http://lists.maptools.org/mailman/listinfo/proj</a></blockquote></div>