This executable test suite (ETS) checks WFS 2.0 implementations for conformance
to the set of specifications 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.
Figure 1 - Relevant specifications
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.
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):
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).
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
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).
Table 2 - Test run arguments
Name
Value domain
Obligation
Description
wfs
URI
M
A URI that refers to a representation of the service capabilities document.
This document does not need to be obtained from the service under test (SUT),
but it must describe the SUT. Ampersand ('&') characters appearing within
a query parameter value must be percent-encoded as %26.
fid
NCName
O
An identifier that matches the @gml:id attribute value of an available feature
instance (may be omitted for "Basic WFS" implementations).
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.