<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&#39;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&#39;t know Catch2 so I don&#39;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">&lt;<a href="mailto:mateusz@loskot.net" target="_blank">mateusz@loskot.net</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 29 May 2018 at 22:02, Kristian Evers &lt;<a href="mailto:kreve@sdfe.dk">kreve@sdfe.dk</a>&gt; wrote:<br>
&gt; On 29 May 2018, at 21:14, Mateusz Loskot &lt;<a href="mailto:mateusz@loskot.net">mateusz@loskot.net</a>&gt; wrote:<br>
&gt;&gt; On Tue, 29 May 2018, 20:37 Kristian Evers, &lt;<a href="mailto:kreve@sdfe.dk">kreve@sdfe.dk</a>&gt; wrote:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; So in summation my proposed TODO list goes something like:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;     1. Move tests from src/ to the Catch2 framework<br>
&gt;&gt;&gt;     2. Move selftest remnants in gie.c to the Catch2 framework<br>
&gt;&gt;&gt;     3. Move shell-script tests in nad/ to test/<br>
&gt;&gt;&gt;     4. Add a test framework for the command line applications, also in<br>
&gt;&gt;&gt; test/<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Thoughts? What have I missed?<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; Although might be to early, but perhaps an outline of tests organization<br>
&gt;&gt; into suites and cases.<br>
&gt;&gt;<br>
&gt;&gt; For example:<br>
&gt;&gt;<br>
&gt;&gt; - test suite per API function - a sort of unit kind of tests focused on<br>
&gt;&gt; exercising single function (similar tests also could verify definitions of<br>
&gt;&gt; data structures). Eg. Call foo(a, b) with valid, invalid, boundary, random,<br>
&gt;&gt; etc. values for parameters.<br>
&gt;&gt;<br>
&gt;&gt; - test suites of more complex test cases, more complex Arrangements<br>
&gt;&gt; preparing for actual test as well as more elaborate assertions following a<br>
&gt;&gt; testing act - I like to think of those as functional tests (function is a<br>
&gt;&gt; black box) or inter-function integration tests :) Eg.  Verifying conversion<br>
&gt;&gt; of X from CRS A to B gives expected results, depending on input valid,<br>
&gt;&gt; invalid, boundary…<br>
&gt;<br>
</span><span class="">&gt; Your first point sounds like something we should do at least. We definitely<br>
&gt; need tests for each function in the library. The second point, if I understand<br>
&gt; 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="HOEnZb"><font color="#888888">-- <br>
Mateusz Loskot, <a href="http://mateusz.loskot.net" rel="noreferrer" target="_blank">http://mateusz.loskot.net</a><br>
</font></span><div class="HOEnZb"><div class="h5">______________________________<wbr>_________________<br>
Proj mailing list<br>
<a href="mailto:Proj@lists.maptools.org">Proj@lists.maptools.org</a><br>
<a href="http://lists.maptools.org/mailman/listinfo/proj" rel="noreferrer" target="_blank">http://lists.maptools.org/<wbr>mailman/listinfo/proj</a></div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">--<div><a href="http://schwehr.org" target="_blank">http://schwehr.org</a></div></div>
</div>