This document explains the process to develop and maintain OGC tests.
Developers mailing list is email@example.com
Development of a New test
A new test starts by creating a new project at GitHub: https://github.com/opengeospatial
The Project name in GitHub should be of the form ets-$abbreviation$version. For example:
- ets-cat30 - refers to the executable test suite for CAT 3.0
- ets-wfs20 - refers to the executable test suite for WFS 2.0
Structure of a test
The test is developed in Java. For new tests it is encouraged to use TestNG. The test is structure in Maven. Example of a test is here.
The version of the test suite is the version of the test and a qualifier. For example: 3.2.1-r01
When test has a new revision, the qualifier will move one up: so 3.2.1-r02
This follows the convention of when the development of the tests started aorund 2004.
- ArtifactId: ets-$abbreviation$revision. For example for GML 3.2.1 it should be: ets-gml32
- Version: Refers to the version of the specification. For example for GML 3.2.1 it should be 3.2.1
- Two property codes are defined:
- ets-code = gml
- spec-version = 3.2.1
- The master branch has always the latest working code
- The master branch has the version of the next release and the qualifier -SNAPSHOT. For example 3.2.1-r5-SNAPSHOT
- The workflow follows the typical GitHub Flow. When a developer is working on an issue or a new feature os a test, the developer creates a branch. When the code is ready the developer pushes the changes or creates a pull request. The test lead is responsible for managing the merge.