<div dir="auto"><div data-smartmail="gmail_signature" dir="auto">On Tue, 29 May 2018, 20:37 Kristian Evers, <<a href="mailto:kreve@sdfe.dk">kreve@sdfe.dk</a>> wrote:</div><div class="gmail_quote" dir="auto"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space">
<div>So in summation my proposed TODO list goes something like:</div>
<div><br>
</div>
<div> 1. Move tests from src/ to the Catch2 framework</div>
<div> 2. Move selftest remnants in gie.c to the Catch2 framework</div>
<div> 3. Move shell-script tests in nad/ to test/</div>
<div> 4. Add a test framework for the command line applications, also in test/</div>
<div><br>
</div>
<div>Thoughts? What have I missed?</div></div></blockquote></div><div dir="auto"><br></div><div dir="auto">Although might be to early, but perhaps an outline of tests organization into suites and cases.<br></div><div dir="auto"><br></div><div dir="auto">For example:</div><div dir="auto"><br></div><div dir="auto">- test suite per API function - a sort of unit kind of tests focused on exercising single function (similar tests also could verify definitions of data structures). Eg. Call foo(a, b) with valid, invalid, boundary, random, etc. values for parameters. </div><div dir="auto"><br></div><div dir="auto">- test suites of more complex test cases, more complex Arrangements preparing for actual test as well as more elaborate assertions following a testing act - I like to think of those as functional tests (function is a black box) or inter-function integration tests :) Eg. Verifying conversion of X from CRS A to B gives expected results, depending on input valid, invalid, boundary... </div><div dir="auto"><br></div><div dir="auto">To me personally, names and definitions of particular testing do not really matter as long as there is agreement, at test case level, about what behaviour is actually being tested and asserted (sticking with single assertion per test case is a good method to reveal smelly places where it is hard to tell what is being tested) </div><div dir="auto"><br></div><div class="gmail_quote" dir="auto"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div> Any suggestions on how to test the command line</div>
<div>applications?</div></div></blockquote></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">Some options:</div><div dir="auto">- extract gist of program logic into utility libraries (technique used in OSRMand GDAL too, AFAIR) </div><div dir="auto">- run programs directly (either via OS-specific C/C++ API or Python or...) and parse/check it's output. </div><div dir="auto"><br></div><div dir="auto"><br></div><div class="gmail_quote" dir="auto"></div><div dir="auto"><span style="font-family:sans-serif">Mateusz Loskot, <a href="mailto:mateusz@loskot.net">mateusz@loskot.net</a></span><br style="font-family:sans-serif"><span style="font-family:sans-serif">(Sent from mobile)</span><br></div><div dir="auto"><br></div><div class="gmail_quote" dir="auto"></div></div>