Test framework for Topaz

Moved from build-system to topaz-testing.

Some maven2 related testing info:

• http://docs.codehaus.org/display/MAVEN/Testing+Strategies
• http://cargo.codehaus.org/Functional+testing

Some usage scenarios:

• top-level build all (e.g. continuous integration): should build the fedora re-package jar, start fedora/kowari, build and run integration tests on everything else, and finally shut fedora down again.
• single package build (e.g. during development on a package): should run tests against a separately started fedora. I.e. starting and stopping of fedora should be separate commands.

(In [241]) Fixed issue with non-guaranteed execution order of plugins in same phase

The java2wsdl and antrun task to copy the output of java2wsdl were both running in the process-classes phase. The copied output was used by the maven-jar-plugin in the packaging phase to put the generated .wsdl in the root of the jar file. And, unfortunately, there were no reasonable phases between process-classes and packaging to shove the ant-task and the maven-jar-plugin is not very configurable. The best solution was to have java2wsdl put the .wsdl into target/classes directly instead of into the default target/generated-sources/axistools/java2wsdl directory.

(I hope I'm not missing some reason the .wsdl wants to be in the generated-sources directory too.)

The problem I was hitting was this pom.xml was inheriting new build information from a new profile I have yet to check-in. And when it did so maven reordered the plugin execution order so the ant-task tried to run before the java2wsdl -- something that obviously errored out. It is clear that maven does not honor the order plugins are placed in a pom.xml when determining what order to run things within a given phase.

re #63 makes inherited profiles possible

(In [261]) re #63 Re-enable integration tests through the it-helper profile

The it-helper profile is defined in head/pom.xml and topazproject/webservices/ */ws-client-impl/pom.xml. If "mvn -Pit-helper integration-tests" is run in any of the ws-client-impl modules, integration tests will be run. However, if the profile is off (default), integration tests are not run and everything builds normally.

Unfortunately, running the it-helper profile outside of the specific sub- modules will fail due to the annoying way maven decises when and how to compute the pom to run. So don't try it! This is phase 1. Phase 2 of the integration test stuff will address that.

Integration test code does assume that fedora and CAS are running.

Integration test code has been moved from src/test to src/it. This is a pattern, not necessarily the best pattern given difficulties getting maven to use this directory as intended. Time will tell.

The it-helper profile defines the following:

• testResources = src/it/resources AND src/test/resources (both needed or unit-tests may break - it is a compromise)
• src/it/java added to test sources via build-helper-maven-plugin
• surefire unit-tests turned off
• surefire integration-tests turned on
• A default configuration for cargo/jetty is defined such that all a sub-module needs to do is define that it wants to use the plugin and all defaults will be pulled in. (This is so that running with this profile in non ws-client-impl modules may still work somewhat.)

How to test

for dir in topazproject/webservices/*/ws-client-impl; \

do (cd $dir; mvn -Pit-helper integration-test); done

(In [295]) Add SPAWN and INSTALL options to ecqs/fedora-install goals

SPAWN will cause either goal to spin-off ecqs or fedora such that you will get your terminal back again. (Although I believe you get your terminal back before either of these are completely started, so be careful.)

INSTALL will cause ecqs/fedora to be installed before their started.

The purpose of both of these is for integration testing (re #63). The integration tests must startup both servers without hanging, run the tests and then shutdown again. Thus SPAWN. Also, there is a bug with maven where it does not honor the order plugins are specified, thus it was necessary to get ant to honor the fact that install should be run before start.

These can be used directly on the command line:

mvn -DSPAWN=true -DINSTALL ant-tasks:ecqs-start

Or, via a plugin to something else:

  <plugin>
    <groupId>org.topazproject.plugins</groupId>
    <artifactId>ant-tasks</artifactId>
    <executions>
      <execution>
        <goals><goal>fedora-start</goal></goals>
        <configuration>
          <INSTALL>true</INSTALL>
          <SPAWN>true</SPAWN>
        </configuration>
      </execution>
    </executions>
  </plugin>

Note: There was a bit of back-and-forth about whether some of the tasks currently defined in the .build.xml files should be converted from using <exec /> to <java /> (or possibly <ant />) with the new antlib stuff, but there are some issues with whether maven uses a JRE or JDK to invoke tasks and I left more things alone than I could have so that hopefully nothing breaks for others.

How to test

Run the following commands:

mvn -DSPAWN=true -DINSTALL ant-tasks:ecqs-start
mvn -DSPAWN=true -DINSTALL ant-tasks:fedora-start

(In [298]) fixes #63 Integration framework for topaz

Please see IntegrationTesting wiki page.

Integration tests are those that assume a container is present. The tests should go into one of two places:

• <your-module>/src/it
• <integrationtests-module>/src/it

Tests are run by:

  cd <integrationtests-module>
  mvn -Pit-startenv clean integration-test

Topaz and plosone will each have their own <integrationtests-module>. Both will be fairly similar, but it is likely different tools may be used. (i.e. plosone might choose to use cactus). That said, head/topazproject/ integrationtests is a pattern that should easily be replicated for plosone.

Maven2 is a bit immature and multiple sources indicated that the best way to implement integration testing at this time was to create a separate module as I've done. However, there is quite a bit of maintenance over- head required to ensure this module keeps working -- primarily, it must have dependencies on all modules and modules those modules depend on to test in its dependency list. This is duplicated effort and there is currently no way around it.

The integrationtests module looks for integration tests in **/src/it in its peer directories and all their subdirectories.

To run tests one-module at a time, please see [261].

NB: If the integration-test stage fails, post-integration-test does not get run. Vincent sent me a possible solution and Ronald and I discussed writing a shell script to integrate into continuum.

How to test

  cd head
  mvn clean install
  cd topazproject/integrationtests
  mvn -Pitstartenv clean integration-test

If any of the tests fail, you may need to shutdown manually:

  mvn ant-tasks:fedora-stop
  mvn ant-tasks:ecqs-stop

(In [315]) re #63 build-and-test goal for use by continuum

So we don't have to drop to a shell script in continuum, this goal will allow us to use the following goals in continuum:

ant-tasks:build-and-test ant-tasks:fedora-stop ant-tasks:ecqs-stop

It does the following:

• Clean the install location (which will wipe the DB and any side-effects from previous "clean install" runs)
• Exec mvn clean install --batch-mode
• Exec cd head/topazproject/integrationtests; mvn clean integration-test --batch-mode

How to test

  mvn --batch-mode \
    ant-tasks:build-and-test ant-tasks:fedora-stop ant-tasks:ecqs-stop

(In [316]) re #63/[315] Forgot to set profile it-startenv when running integrationtests

Milestone Bugs deleted