Functional Mojo Testing

Owned by bcarlsen (Unlicensed)
Last updated: Jun 26, 2015
1 min read

Overview

Information on integration/functional testing for the admin tool mojos.

Coverage

These admin will be covered by mojo integration testing.

  • LuceneReindexMojo
  • ProjectLoaderMojo
  • ProjectRemoverMojo
  • StartEditingCycleMojo.java
  • TerminologyClamlLoaderMojo
  • TerminologyRemoverMojo
  • TerminologyRf2SnapshotLoaderMojo

  • TerminologyRrfLoaderMojo

  • UpdateDbMojo

Complete coverage would involve calling a series of mojos to enact a standard "scenario" and then verifying the outcome of that scenario. Mojos should be tested in both "server" and "noserver" modes.

Coverage Definition

Coverage is defined as series of load and unload tests in the various formats that verify that both the mojos function properly and the requisite data is loaded (or removed).

Assumptions

  • A dev database exists that contains no data (though schema tables may be present)
  • At the conclusion of the test, the dev database again contains no data (so the test can be easily re-run).
  • A server built using the latest code is deployed to the URL specified in the base.url property of the config file used to run the integration tests.
  • The server is configured to use "default" authentication in which "guest" and "admin" users can be authenticated with any password (and the auth token matches the usernames)

Organization

Integration tests are organized under the integration-testing-mojo project.  Looking through the Java packages, you should find a "com.wci.umls.server.test.mojo" package that defines a number of test classes that represent the coverage spreadsheet.  These are separate from the other integration-test packages as typically a different "run.config.umls" file is used (pointing to an empty database).

Integration Test Cases

Following are the test case sequences for mojo validation.

  • n/a

 

.