Testing¶

JUnit¶

The well known JUnit framework is the primary test library used in GeoServer. The current version used is Junit 4.x. While it is possible to continue to write JUnit 3.x style tests with JUnit 4, new tests should be written in the JUnit4 style with annotations.

Current version: 4.11

XMLUnit¶

The XMLUnit library provides a convenient way to make test assertions about the structure of XML documents. Since many components and services in GeoServer output XML, XMLUnit is a very useful library.

Current version: 1.3

MockRunner¶

The MockRunner framework provides a set of classes that implement the various interfaces of the J2EE and Java Servlet apis. It is typically used to create HttpServletRequest , HttpServletResponse, etc… objects for testing servlet based components.

Current version: 0.3.6

EasyMock¶

The EasyMock library is a mocking framework that is used to simulate various objects without actually creating a real version of them. This is an extremely useful tool when developing unit tests for a component A, that requires component B when component B may not be so easy to create from scratch.

Current version: 2.5.2

Unit¶

Tests that exercise a particular method/class/component in complete isolation. In GeoServer these are tests that typically don’t extend from any base class and look like what one would typically expect a unit test to look like.

Integration/Mock¶

Tests that exercise a component by that must integrate with another component to operate. In GeoServer these are tests that somehow mock up the dependencies for the component under test either by creating it directly or via a mocking library.

System¶

Tests that exercise a component or set of components by testing it in a fully running system. In GeoServer these are tests that create a fully functional GeoServer system, including a data directory/configuration and a spring context.

Helper classes are provided to help inject your classes into the system configuration including GeoServerExtensionsHelper.

Single vs Repeated Setup¶

By default, for performance reasons, the setup phase is executed only once for a system test. This can however be configured by annotating the test class with a special annotation named TestSetup. For example, to specify that the setup should be executed many times, for each test method of the class:

@TestSetup(run=TestSetupFrequency.REPEAT)
public class MyTestCase extends GeoServerSystemTestSupport {
   ...
}

This however should be used only as a last resort since as mentioned before a repeated setup makes the test execute very slowly. An alternative to a repeated setup is to have the test case revert any changes that it makes during its execution, so that every test method can execute in a consistent state. The GeoServerSystemTestSupport contains a number of convenience methods for doing this. Consider the following test:

public class MyTestCase extends GeoServerSystemTestSupport {

   @Before
   public void revertChanges() {
       //roll back any changes made
       revertLayer("foo");
   }

   @Test
   public void testThatChangesLayerFoo() {
      //change layer foo in some way
   }
}

The test makes some changes to a particular layer but uses a before hook to revert any such changes. In general this is the recommended pattern for system tests that must are not read-only and must modify configuration or data to execute.

Method Level SetUp¶

A third method of controlling test setup frequency is available at the test case level. Annotating a test method with the RunTestSetup annotation will cause the test setup to be run before the test method is executed. For example:

public class MyTestCase extends GeoServerSystemTestSupport {

   @Before
   public void revertChanges() {
       //roll back any changes made
       revertLayer("foo");
   }

   @Test
   public void test1() {
   }

   @Test
   public void test2() {
   }

   @Test
   @RunTestSetup
   public void test3() {

   }

   @Test
   public void test4() {
   }

}

In the above method the test setup will be run twice. Once before the entire test class is run, and again before the test3 method is executed.

Setup/Teardown Hooks¶

There are a number of ways to hook into test lifecycle to provide setup and tear down functionality.

public class MySystemTest extends GeoServerSystemTestBase {

   protected void setUpTestData(SystemTestData testData) {
      // do the default by calling super
      super.setUpTestData(testData);

      // add raster layers
      testData.setUpDefaultRasterLayers();
   }
}

public class MySystemTest extends GeoServerSystemTestBase {

    Catalog catalog;

    @Override
    protected void onTestSetup(SystemTestData testData) throws Exception {
       // add a layer named foo to the catalog
       Catalog catalog = getCatalog();
       catalog.addLayer(new Layer("foo"));

       // initialize the catalog field
       this.catalog = catalog;
    }

    @Test
    public void test1() {
       catalog.getLayerByName("foo");
    }

    @Test
    public void test2() {
       catalog.getLayerByName("foo");
    }
}

public class MySystemTest extends GeoServerSystemTestBase {

    Catalog catalog;

    @Override
    protected void onTestSetup(SystemTestData testData) throws Exception {
       // add a layer named foo to the catalog
       Catalog catalog = getCatalog();
       catalog.addLayer(new Layer("foo"));

       // initialize the catalog field
       this.catalog = catalog;
    }

    @Before
    public void initCatalog() {
        this.catalog = getCatalog();
    }
}

System Test Data¶

The GeoServer system test will create a data directory with a standard set of vector layers. The contents of this data directory are as follows:

@Override
protected void setUpInternal(SystemTestData data) throws Exception {
    DataStoreInfo storeInfo =
            createShapefileDataStore(getCatalog(), "tasmania_roads", "tasmania_roads.shp");

    createShapeLayer(getCatalog(), storeInfo);
}

private static DataStoreInfo createShapefileDataStore(
        Catalog catalog, String name, String file) {
    // get the file
    URL url = MultiDimensionTest.class.getResource(file);
    assertThat(url, notNullValue());
    // build the data store
    CatalogBuilder catalogBuilder = new CatalogBuilder(catalog);
    DataStoreInfo storeInfo = catalogBuilder.buildDataStore(name);
    storeInfo.setType("Shapefile");
    storeInfo.getConnectionParameters().put(ShapefileDataStoreFactory.URLP.key, url);
    catalog.add(storeInfo);
    storeInfo = catalog.getStoreByName(name, DataStoreInfo.class);
    assertThat(storeInfo, notNullValue());
    return storeInfo;
}

private static LayerInfo createShapeLayer(Catalog catalog, DataStoreInfo storeInfo)
        throws Exception {
    CatalogBuilder catalogBuilder = new CatalogBuilder(catalog);
    catalogBuilder.setStore(storeInfo);
    Name typeName = storeInfo.getDataStore(null).getNames().get(0);
    FeatureTypeInfo featureTypeInfo = catalogBuilder.buildFeatureType(typeName);
    catalog.add(featureTypeInfo);
    LayerInfo layerInfo = catalogBuilder.buildLayer(featureTypeInfo);
    catalog.add(layerInfo);
    layerInfo = catalog.getLayerByName(typeName.getLocalPart());
    assertThat(layerInfo, notNullValue());
    return layerInfo;
}

Document dom = getAsDOM("wfs?request=GetFeature&typenames=gs:tasmania_roads&version=2.0.0&service=wfs");

EasyMock Class Extension¶

By default EasyMock can only mock up interfaces. To mock up classes requires the EasyMock classextension jar and also the cglib library. These can be declared in a maven pom like so:

<dependency>
  <groupId>org.easymock</groupId>
  <artifactId>easymockclassextension</artifactId>
  <scope>test</scope>
</dependency>
<dependency>
  <groupId>cglib</groupId>
  <artifactId>cglib-nodep</artifactId>
  <scope>test</scope>
</dependency>

The change is mostly transparent, however rather than importing org.easymock.EasyMock one must import org.easymock.classextension.EasyMock.