Difference between revisions of "Opentaps 2 Automated Testing"
(→Checking the tests results)
|Line 77:||Line 77:|
Latest revision as of 22:50, 27 January 2012
opentaps 2 Automated Testing
opentaps 2 supports both unit and integration testing.
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
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:
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:
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.
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
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:
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.