Tests Developers

Motivation

This document explains the process to develop and maintain OGC tests.

Developers List

Developers mailing list is cite-dev@lists.opengeospatial.org

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. 

 

Versioning

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.

Maven properties

  • 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


Workflow

  • 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.