WFS 2.0 (ISO 19142:2010) Conformance Test Suite

Scope

This executable test suite (ETS) checks WFS 2.0 implementations for conformance with respect to ISO 19142:2010 (Geographic information -- Web feature service) and related standards as depicted in Figure 1. Conformance testing is a kind of "black box" testing that examines externally visible characteristics or behaviors of the SUT and is independent of any implementation details.

Several fundamental conformance levels are defined in ISO 19142:

Simple WFS

Implements the following operations: GetCapabilities, DescribeFeatureType, ListStoredQueries, DescribeStoredQueries, and the GetFeature operation with at least the StoredQuery action (GetFeatureById).

Basic WFS

As for Simple WFS, plus the GetFeature operation with the Query action and the GetPropertyValue operation.

Transactional WFS

As for Basic WFS, plus the Transaction operation.

Locking WFS

As for Transactional WFS, plus at least one of the GetFeatureWithLock or LockFeature operations.

Test requirements

The documents listed below stipulate requirements that must be satisfied by a conforming implementation.

• [ISO 19142:2010] Geographic information -- Web Feature Service. Also published as OGC 09-025r1.
• [ISO 19143:2010] Geographic information -- Filter encoding. Also published as OGC 09-026r1.

The test suite is schema-aware in the sense that the WFS under test does not need to support any particular application schema or to be loaded with specialized test data. However, the following preconditions must be satisfied by the implementation under test (IUT):

1. The GML application schema meets the requirements of the GML conformance class "GML application schemas defining features and feature collections" (ISO 19136, A.1.4).
2. Data are available for at least one feature type advertised in the capabilities document.

A feature identifier may be supplied for the purpose of verifying the behavior of the GetFeatureById stored query. If this test run parameter is missing or does not identify an available feature instance, a "Simple WFS" implementation must also implement the GetFeatureByType stored query (see the definition below). The parameter may be omitted if the WFS under test implements the "Basic WFS" conformance class.

<wfs:StoredQueryDefinition id="urn:ogc:def:query:OGC-WFS::GetFeatureByType"
  xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <wfs:Abstract>
    A parameterized GetFeature request that returns a collection of features by type name.
  </wfs:Abstract>
  <wfs:Parameter name="typeName" type="xs:QName">
    <wfs:Abstract>A QName specifying a feature type name (required); a corresponding namespace 
    binding must also be present.</wfs:Abstract>
  </wfs:Parameter>
  <wfs:Parameter name="startIndex" type="xs:nonNegativeInteger">
    <wfs:Abstract>Default value is 0</wfs:Abstract>
  </wfs:Parameter>
  <wfs:Parameter name="count" type="xs:nonNegativeInteger">
    <wfs:Abstract>Optional</wfs:Abstract>
  </wfs:Parameter>
  <wfs:QueryExpressionText returnFeatureTypes="gml:AbstractFeature"
    language="http://schemas.opengis.net/wfs/2.0/wfs.xsd#xmlns(wfs=http://www.opengis.net/wfs/2.0)xscd(/wfs:GetFeature)">
    <wfs:GetFeature startIndex="${startIndex}" count="${count}">
      <wfs:Query typeNames="tns:${typeName}"/>
    </wfs:GetFeature>
  </wfs:QueryExpressionText>
</wfs:StoredQueryDefinition>
    

Test coverage

Several optional conformance classes are not covered by the current test suite. The following capabilities are not tested:

• Inheritance
• Remote resolve
• Response paging
• Standard joins
• Spatial joins
• Temporal joins
• Feature versions
• Manage stored queries

Test suite structure

The test suite definition file (testng.xml) is located in the root package, org.opengis.cite.iso19142. A conformance class corresponds to a <test> element; each test element includes a set of test classes that contain the actual test methods. The general structure of the test suite is shown in Table 1. Note that some schema-related tests are imported from the GML 3.2 test suite.

The Javadoc documentation provides more detailed information about the test methods that constitute the suite.

How to run the tests

The test suite may be run in any of the following environments:

• Integrated development environment (IDE): The main Java class is TestNGController.
• REST API: Submit a request that includes the necessary arguments to the test run controller (/rest/suites/${ets-code}/${project.version}/run).
• TEAM-Engine: Run the CTL script located in the /src/main/ctl/ directory.

The test run arguments are summarized in Table 2. The Obligation descriptor can have the following values: M (mandatory), O (optional), or C (conditional).

Note: A test method is skipped if any preconditions were not satisfied. Test prerequisites are usually checked in a configuration method; the results of these can be viewed in the TestNG report by selecting the "Config" check box.