[Proj] Testing of proj

[Kurt Schwehr]

Kristian,

Thanks for the overview!

Turns out it is super easy to wrap gie and use it in my bazel world.  Just
required the python below.  When it fails, the error message isn't pretty,
but that's for another day :)

-kurt

class GigsTest(googletest.TestCase):

  def setUp(self):
    self.gie = os.path.join(resources.GetARootDirWithAllResources(),
                            'third_party/proj4/gie')

  def testAll(self):
    glob_path = os.path.join(FLAGS.test_srcdir,
                             'third_party/proj4/proj/test/gigs', '*.gie')
    gie_files = glob.glob(glob_path)
    self.assertTrue(gie_files)
    for filepath in gie_files:
      cmd = [self.gie, filepath]
      result = subprocess.check_output(cmd, stderr=subprocess.STDOUT)
      self.assertIn('0 tests failed', result)


if __name__ == '__main__':
  unittest.main()


On Thu, Mar 8, 2018 at 3:44 AM, Kristian Evers <kreve at sdfe.dk> wrote:

> Hi Kurt,
>
>
>
> Very cool to increase the testing effort. Thanks!
>
>
>
> Testing is still a bit of a mess, although with the gie test program we’ve
> come a long way.
>
> There’s not much documentation on this yet (contributions welcome :-)).
> The best source
>
> right now is the Travis setup I guess. See that for details. I’ll try to
> give a brief explanation
>
> of what’s going on.
>
>
>
> There’s tests in two places in the source tree at the moment. In nad/ and
> in test/. The tests
>
> in nad/ are from way back when and are made up of a set of shell scripts
> that call cs2cs
>
> and checks the results by diff’ing the output towards an existing
> “solution”. The other tests
>
> in test/ are the new setup which eventually will be the main test setup I
> think. They only test
>
> the new API though, so the old tests are the only place where cs2cs is
> properly tested.
>
>
>
> I’d like to clean this stuff up a bit. I’ll try to find the time and
> energy to lay out a proper plan
>
> for that effort.
>
>
>
> You can run all tests with either `make check´ (autotools builds) or
> `ctest` (cmake builds).
>
>
>
> I hope that is good enough for now. Suggestions on how and where to
> document this stuff
>
> are welcome.
>
>
>
> /Kristian
>
>
>
> *Fra:* proj-bounces at lists.maptools.org [mailto:proj-bounces at lists.
> maptools.org] *På vegne af *Kurt Schwehr
> *Sendt:* 7. marts 2018 18:34
> *Til:* PROJ.4 and general Projections Discussions <proj at lists.maptools.org
> >
> *Emne:* [Proj] Testing of proj
>
>
>
> Hi all,
>
>
>
> In case anyone is interested, I've just pushed my first set of tests for
> proj to my GDAL autotest2 "third_party" trees.  Nothing super exciting, but
> this is some of the stuff I count on for CI.
>
>
>
> Python subprocess minimally testing cs2cs:
>
>     https://github.com/schwehr/gdal-autotest2/tree/master/
> python/third_party/proj
>
>
>
> C++ gunit tests - not well thought out and very little coverage:
>
>     https://github.com/schwehr/gdal-autotest2/tree/master/
> cpp/third_party/proj
>
>
>
> I have yet to wrap existing proj tests to a gunit/python unittest/bazel
> world.  Any chance someone could point me at more docs about the testing
> strategy for proj 5 and going forward?  There isn't much here:
> http://proj4.org/contributing.html
>
>
>
> I see these, but which are the most important going forward?  It appears
> that porting the gie infrastructure with the gigs test cases is probably
> the best place to start.  Does that make sense?
>
>
>
> Are binaries like cs2cs tested anywhere?  I can't seem to find anything.
>
>
>
> ls test
>
> CMakeLists.txt  Makefile.am     fuzzers         gie             gigs
>
>
>
> ls cmake | grep -i test
>
> Proj4Test.cmake
>
>
>
> cd src; ls | egrep -i 'gie|test'
>
> bin_geodtest.cmake
>
> bin_gie.cmake
>
> geodtest.c
>
> gie.c
>
> multistresstest.c
>
> runmultistresstest.sh
>
> test228.c
>
>
>
> -kurt
>
> _______________________________________________
> 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/20180309/021ecc15/attachment.html>