Opentaps 2 Automated Testing

opentaps 2 Automated Testing

opentaps 2 supports both unit and integration testing.

Unit Tests

Running the tests

To run unit tests:

mvn -DskipTests=false verify

To run both unit tests and integration tests:

mvn -DskipTests=false -Dit verify

Also when running unit tests one can chose to run only one test, for example:

 mvn verify -DskipTests=false -Dtest=ValidationTest

where -Dtest=<name of the unit test classes (can be comma separated)>

Checking the tests results

For unit tests, the output can be found for each module, for example at

 ./modules/notes/impl/tests/target/surefire-reports/

How to setup unit tests with Pax Exam

Because the integration tests runs Geronimo it can take quite some time to start and run, which can be discouraging when doing TDD or simply wanting to test a particular case.

As an example, in `./modules/notes/impl/tests/` is the module containing the unit tests for the `notes` module.

First is the Pax Exam configuration class:

./modules/notes/impl/tests/src/test/java/org/opentaps/notes/tests/NotesTestConfig.java 

Its role is to configure the OSGI environment in which the tests will be run by listing the bundles to be started. Some of those constitute an environment similar to what is provided by the Geronimo server : JPA, transactions, aries blueprint, apache bval, and their dependencies etc .. the others are the API and implementation bundles of the module we are testing.

Worth noting is the org.opentaps.validation.testimpl bundle which replaces org.opentaps.validation.impl during unit testing as a way to bootstrap and provide JSR303 validation.

Second are the JUnit style unit tests, they all extend the configuration class, for example:

./modules/notes/impl/tests/src/test/java/org/opentaps/notes/tests/NoteApiTest.java

The only particularities here are the @RunWith(JUnit4TestRunner.class) annotation which allows Pax Exam to run it as a JUnit unit test, and the @Inject annotations that will inject the OSGI services.

Integration Tests

During integration testing opentaps bundles are combined into application, deployed to Geronimo instance and tested as integrated system.

Running the tests

In order to run this kind of tests you have to activate "it" profile with the following command line:

mvn -Dit verify

or

mvn -Dit -DgeronimoHome=/path/to/geronimo/dir verify

Note the difference. First command line uses fresh copy of Geronimo every run, second one uses a preinstalled Geronimo and is helpful if you want to test applications with extra configuration changes or modules not included into release distribution.

Also you can choose to run single test case

mvn -Dit -Dit.test=TestsClass verify

or even single test

 mvn -Dit -Dit.test=TestsClass#testMethod verify

Checking the tests results

Integration tests results can be checked in the maven output and a report at:

 ./integration-tests/tests-run/target/site/failsafe-report.html

Principles

There are three modules under integration-tests and they are responsible for integration testing. tests-run plays most important role. It creates test application from dependencies that are specified in its POM and control tests execution flow. tests-app implements number of testing services which do actual testing and return error message on failure. tests-wab is a simple web application bundle implementing servlet that receive requests initiated in tests-run and call services in tests-app. Something like glue for the first two.

Let's look narrowly at tests-run. Maven defines three phases for integration testing: pre-integration-test, integration-test, post-integration-test and verify to execute tests. During these phases the module do the following:

• pre-integration-test: start an instance of Geronimo and deploy test application
• integration-test: execute unit tests implemented in the module
• post-integration-test: undeploy test application, stop the instance of Geronimo and generate report.

Note some configuration items in POM. By default we run Gerinimo based on Tomcat 7 but you may change this approach in favour of Jetty based distribution in <defaultAssemblyId>. Also, you may find useful memory and debug (disabled by default) option sets.

During integration-test phase Maven execute unit tests. Usually they do not test anything but send requests to server and call test services from tests-app module. URL may look like /itest?service=TestServiceInterface&test=testMethod. Servlet from tests-wab parses the URL, lookup service TestServiceInterface and call its method testMethod which has no arguments and must return error message on failure. This service should make all testing work. This approache may have exeptions. Application code can have own way to accept requests by HTTP or another protocol. In this case it does not make sense call back services in such way. Test may do all work in tests-run unit tests as it implemented in org.opentaps.testsuit.notes.NotesTests which appears for a RESTful client application.