[Geoapi-devel] Refactoring of GIGS tests

[Martin D. <mar...@ge...>]

Hello all

The GeoAPI conformance module implemented the Geospatial Integrity of
Geoscience Software <http://www.iogp.org/Geomatics#2521115-gigs> (GIGS)
tests in two classes: Series2000Test and Series3000Test. Those classes
took their data directly from CSV files derived from GIGS Excel files.
But according our experience, they were difficult to use. For example it
was hard to personalize the tests applied on only a few selected CRS. In
case of test failure, it was difficult for an implementor to debug his
software with break points because the failure happened after an
arbitrary amount of iterations in a loop.

In the hope to make GIGS tests extension, execution and debugging
easier, I propose to split the SeriesXXXX classes in many classes, one
for each GIGS test. Each row in a GIGS test file is exactly one method
in the JUnit test class. I have done this change on Series2000Test in
order to test feasibility. The result is there:

    http://www.geoapi.org/geoapi-conformance/apidocs/org/opengis/test/referencing/gigs/package-summary.html

Currently, the Series3000Test class still implements the old approach
while the GIGS2001, GIGS2002, GIGS2003, GIGS2004, GIGS2005, GIGS2006,
GIGS2007, GIGS2008 and GIGS2009 classes are refactoring of the previous
Series2000Test class. This allows comparison of both approaches. The
GIGS2004 class for example contains 355 test methods: one for the “World
Geodetic System 1984” geodetic datum, one for the “Tokyo” geodetic
datum, one for “European Datum 1950”, /etc./ For each method the javadoc
gives the test data (expected EPSG name, /etc./). This makes tests
personalisation and debugging by implementors much more straightforward
than it was previously.

Do we have an agreement for this proposed new approach? The
possibilities are:

  * Adopt this new approach and apply the same refactoring on the
    Series3000Test class.
  * Reject this approach and revert the GIGS200x classes to the previous
    Series2000Test class.
  * Mix of both (details would need to be discussed).


    Martin