[Proj] Testing framework

Mateusz Loskot mateusz at loskot.net
Tue May 29 13:57:29 PDT 2018


On 29 May 2018 at 22:02, Kristian Evers <kreve at sdfe.dk> wrote:
> On 29 May 2018, at 21:14, Mateusz Loskot <mateusz at loskot.net> wrote:
>> On Tue, 29 May 2018, 20:37 Kristian Evers, <kreve at sdfe.dk> wrote:
>>>
>>> So in summation my proposed TODO list goes something like:
>>>
>>>     1. Move tests from src/ to the Catch2 framework
>>>     2. Move selftest remnants in gie.c to the Catch2 framework
>>>     3. Move shell-script tests in nad/ to test/
>>>     4. Add a test framework for the command line applications, also in
>>> test/
>>>
>>> Thoughts? What have I missed?
>>
>>
>> Although might be to early, but perhaps an outline of tests organization
>> into suites and cases.
>>
>> For example:
>>
>> - 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.
>>
>> - 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…
>
> Your first point sounds like something we should do at least. We definitely
> need tests for each function in the library. The second point, if I understand
> correctly, is more or less covered by gie tests.

Yes, I think so.

Although, there are some cases where such Catch-based functional testing
may be a good idea. For example, verification that pj_init and
pj_init_plus for the
same definition result in equialent instance of projPJ; any kind of verification
of library/object states following interleaved/sequenced API calls;
any kind of round-trips verification with assertions for intermediate results
Such functional tests typically have more assertions per case than unit tests.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net



More information about the Proj mailing list