[Proj] Testing framework

[Kristian Evers]

Mateusz,

That was a good assumption at the time :-) Things are a little bit different now.
It would seem that Catch2 is also good for C code, yes? Obviously compiled
with a C++ compiler. The documentation is a bit vague on this (it just says that
maybe it works).

I am working on a proposal to improve testing of the existing code. So far I have
been working under the assumption that Catch2 would work for testing the
C code we have now. If not I will change that to cunit but it would definitely be
nice to just use one framework.

/Kristian

On 29 May 2018, at 20:02, Mateusz Loskot <mateusz at loskot.net<mailto:mateusz at loskot.net>> wrote:

Kristian, as you know, I've been considering PROJ API tests.
I assumed it would must be in C, so an obvious choice was cunit (as used in PostGIS for instance). I haven't arrived with anything though.

It's just a comment, not recommendation to stick with C and cunit.

Mateusz Loskot, mateusz at loskot.net<mailto:mateusz at loskot.net>
(Sent from mobile)

On Tue, 29 May 2018, 19:26 Kristian Evers, <kreve at sdfe.dk<mailto:kreve at sdfe.dk>> wrote:
Even,

Your timing is perfect. I was literally just typing up a long email about improving
the test situation in PROJ right now! I was going to propose a larger restructuring
of the tests we already have as well as adding a dedicated testing framework for
testing API functions etc. You’ve taken care of the latter and most pressing issue.
I’ll address the rest of my proposal at a later time I think.

I have only looked briefly at catch2 but it seems good to me. I am happy that you’ve
put your tests in test/.

/Kristian

> On 29 May 2018, at 19:15, Even Rouault <even.rouault at spatialys.com<mailto:even.rouault at spatialys.com>> wrote:
>
> Hi,
>
> I was researching a framework to test my new code (and that could also be used
> to test the existing C API if needed). Currently src/gie.c has ad-hoc testing,
> but it is really limited feature-wise: no nice error message (returns error
> code), no way to make a testcase go on even if a test check fails, etc...
>
> So a dedicated framework seems a better idea, and I've found catch2 :
>       https://github.com/catchorg/Catch2/blob/master/docs/Readme.md
>
> One of its main feature it is a header only testing framework, which means we
> can embed it easily in proj source tree, which is practical compared to other
> frameworks I've considered ( googletest, cppunit,  etc... ).
> The tut framework used by GDAL and GEOS
> ( http://mrzechonek.github.io/tut-framework ) would also enter this category
> of header(s) only, but it has not as much as activity than catch2.
> There's also Boost.Test, but I was a bit afraid with the boost name in it
> (although apparently it has a standalone mode).
>
> Example of tests I've just written with catch2 (just a minimalistic use of the
> testing framework)
> https://github.com/rouault/proj.4/blob/iso19111_ptr/test/cpp/test_crs.cpp
>
> I'm not particularly calling for a flame debate on the suject, just wanting to
> mention this finding.
>
> Even
>
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com<http://www.spatialys.com/>
> _______________________________________________
> Proj mailing list
> Proj at lists.maptools.org<mailto:Proj at lists.maptools.org>
> http://lists.maptools.org/mailman/listinfo/proj

_______________________________________________
Proj mailing list
Proj at lists.maptools.org<mailto:Proj at lists.maptools.org>
http://lists.maptools.org/mailman/listinfo/proj
_______________________________________________
Proj mailing list
Proj at lists.maptools.org<mailto:Proj at lists.maptools.org>
http://lists.maptools.org/mailman/listinfo/proj

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20180529/95c5ab05/attachment.html>