[Proj] Testing framework

[Mateusz Loskot]

On 30 May 2018 at 22:36, Even Rouault <even.rouault at spatialys.com> wrote:
>> > I'm pretty sure for our basic needs whatever modern unit testing framework
>> > would do. catch2 with
>> > its single header was just easier to integrate, and thus passed the least
>> > effort principle.
>>
>> In short term, perhaps.
>>
>> I've just realised that for the API unit tests I'm planning to write almost
>> exactly the same tests as Kurt has already written.
>>
>> To me, that's just confirmed diagnosis of the problem. For long term, it's
>> gonna be worse.
>> I know I'm not the major contributor here or contributor to be,
>> it's just my earlier disappointment about Kurt's test not actually
>> replacing my initial/old GDAL C++ tests.
>> This seems to be lost opportunity or waste of parallel efforts trying to
>> achieve the same goal - nobody runs autotest2 but Kurt, users who build
>> from sources do not run them, etc.
>>
>> I fear that this pattern is spreading now across not one GDAL but multiple
>> OSGeo libraries.
>
> I'm also sad about this situation of efforts done in parallel of upstream
> projects. If Kurt wants to integrate his tests for the PROJ part using GTest,
> I'm happy with that, but that should be done quickly before I have too many
> catch2 tests written.

Even, I appreciate that.
I hope it's not a rashly change.
Assuming there are no objections, I can help Kurt

> In the PROJ context, that would mean having both a
> automake and cmake way of building GTest (probably GTest minimum code &
> headers integrated in proj source tree for conveniency ?). I'm not really
> confortable enough with build systems to do such an effort for a test
> framework.

I can do it next after the weekend  (public holiday in PL and long
weekend away).
Luckily, FindGTest guesser for CMake comes with the official package
since CMake 3.0.
I can also do it for Autoconf.

Kurt, let me know (off-list fine) if you need help.

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