[Proj] Testing framework
schwehr at gmail.com
Wed May 30 15:56:56 EST 2018
If we go with GoogleTest, the instructions for CMake and autotest are here:
I've never done the CMake or autoconf setups.
On Wed, May 30, 2018 at 1:36 PM, Even Rouault <even.rouault at spatialys.com>
> > > I'm pretty sure for our basic needs whatever modern unit testing
> > > would do. catch2 with
> > > its single header was just easier to integrate, and thus passed the
> > > effort principle.
> > In short term, perhaps.
> > I've just realised that for the API unit tests I'm planning to write
> > exactly the same tests as Kurt has already written.
> > To me, that's just confirmed diagnosis of the problem. For long term,
> > 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
> > 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
> I'm happy with that, but that should be done quickly before I have too
> 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
> Spatialys - Geospatial professional services
> Proj mailing list
> Proj at lists.maptools.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Proj