[Proj] Testing framework

[Even Rouault]

> > 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. 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.

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com