[Proj] Testing framework

[Mateusz Loskot]

Hi,

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.
This is unfortunate situation that such valuable continuous efforts like
autotest2 lives outside the upstreams.
It would be pity if this situation clones into PROJ.


Mateusz Loskot, mateusz at loskot.net
(Sent from mobile)

On Wed, 30 May 2018, 20:36 Kurt Schwehr, <schwehr at gmail.com> wrote:

> 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.
>
> I really don't know Catch2 so I don't really have an opinion on how well
> it works.
>
> Either way, I will keep on doing PROJ/GEOS/GDAL testing in gtest for my
> own work.
>
> On Tue, May 29, 2018 at 1:57 PM, Mateusz Loskot <mateusz at loskot.net>
> wrote:
>
>> 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
>> _______________________________________________
>> Proj mailing list
>> Proj at lists.maptools.org
>> http://lists.maptools.org/mailman/listinfo/proj
>>
>
>
>
> --
> --
> http://schwehr.org
> _______________________________________________
> Proj mailing list
> Proj at lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/proj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.maptools.org/pipermail/proj/attachments/20180530/e135e26a/attachment.htm