[Proj] Testing framework

[Kurt Schwehr]

My requests:

1. Please do not use Boost.Test.  I can't use that in my bazel based env
(at least without suffering some serious pain)
2. Please do not use a pure C based framework (e.g. Mateusz's comment about
cunit)

I personally prefer GoogleTest + https://github.com/google/benchmark, but
that's probably not surprising given that I work at Google :)

I see a few projects using Catch2, so I can adopt those tests easier than I
did with TUT.  I got TUT working under bazel, but it wasn't fun.

Any way you cut it, it's not too big of a deal to have a third_party/ tree
for the testing framework.  They are all pretty small.

If Proj goes with GoogleTest (gunit), I have these:

https://github.com/schwehr/gdal-autotest2/tree/master/cpp/third_party/proj

I'd be happy to submit any of them to Proj under the Proj license.  I'm
just using gdal-autotest2 as a place to let folks see them.  I also use
python's unittest to driving testing binary command lines.  They aren't the
most exciting tests ever and not much coverage yet, but they help to keep
my stress level to a minimum. Some of these will take a little bit of
cleanup to remove some Google specific things like how to find gie files.



On Tue, May 29, 2018 at 10:43 AM, Mateusz Loskot <mateusz at loskot.net> wrote:

> Hi,
>
> (sorry for top-posting, writing from rubbish mobile gmail)
>
> As initial creator of GEOS tests who introduced TUT, I recommend to not to
> use TUT. So, Even, good you don't.
> It has been added ages ago when there where no decent lightweight testing
> frameworks alternatives.
>
> I use Boost.Test, Catch and Google Test, all have pros and cons, there's
> no clear winner regarding features, IMHO.
>
> Regarding Catch, I suggest to use Catch2, not 1.x line.
>
> Mateusz Loskot, mateusz at loskot.net
> (Sent from mobile)
>
> On 29 May 2018 7:16 pm, "Even Rouault" <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
> _______________________________________________
> Proj mailing list
> Proj at lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/proj
>
>
>
> _______________________________________________
> Proj mailing list
> Proj at lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/proj
>



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