Conformance Test Suite - GML Documents

Scope

This test suite validates the content of a GML 3.2 instance document.

Visit the project documentation website for more information, including the API documentation.

How to run the tests

The test suite is built using Apache Maven v3. The options for running the suite are summarized below.

1. Integrated development environment (IDE)

Use a Java IDE such as Eclipse, NetBeans, or IntelliJ. Clone the repository and build the project.

Set the main class to run: org.opengis.cite.gml32.data.TestNGController

Arguments: The first argument must refer to an XML properties file containing the required test run arguments. If not specified, the default location at $ {user.home}/test-run-props.xml will be used.

You can modify the sample file in src/main/config/test-run-props.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE properties SYSTEM "http://java.sun.com/dtd/properties.dtd">
<properties version="1.0">
  <comment>Test run arguments</comment>
  <entry key="iut">http://schemas.geosciml.org/geosciml/4.0/examples/GSML4-Borehole.xml</entry>
</properties>

The TestNG results file (testng-results.xml) will be written to a subdirectory in ${user.home}/testng/ having a UUID value as its name.

2. Command shell (console)

One of the build artifacts is an "all-in-one" JAR file that includes the test suite and all of its dependencies; this makes it very easy to execute the test suite in a command shell:

java -jar ets-gml32-data-0.1-SNAPSHOT-aio.jar [-o|--outputDir $TMPDIR] [test-run-props.xml]

3. OGC test harness

Use TEAM Engine, the official OGC test harness. The latest test suite release are usually available at the beta testing facility. You can also build and deploy the test harness yourself and use a local installation.

How to contribute

If you would like to get involved, you can:

• Report an issue such as a defect or an enhancement request
• Help to resolve an open issue
• Fix a bug: Fork the repository, apply the fix, and create a pull request
• Add new tests: Fork the repository, implement and verify the tests on a new topic branch, and create a pull request (don't forget to periodically rebase long-lived branches so there are no extraneous conflicts)