Running Tests in tDAR
We use a number of maven tools/plugins to run and manage tests in tDAR. These include, surefire, failsafe, and a custom profile. Currently we have 3 types of tests in tDAR (unit tests, integration tests, and web tests).
Running tests:
| Test Type | Code to Run Test | Description | Naming Convention | Can be run in Eclipse JUnit Tester |
|---|---|---|---|---|
| Unit Tests | mvn -Ptest clean test | These run simple unit tests that test basic logic and functionality in the code without the need for Spring, Hibernate or a web environment. Examples are parts of the filestore, string cleaning, etc. | All test class names should end with Test. | Yes |
| Integration Tests | mvn -Ptest clean verify | These are more complex tests of the tDAR application logic and use a test database, spring, struts2, hibernate. These test full application logic and controller issues as well as database interaction. These tests are susceptible to being run inside of Eclipse's Junit test runner but require the test database to be setup ahead of time. Tests can be targeted by using the property: it.test=MyTestClassSimpleName. | All test class names should end with ITCase. | Yes |
| Web Tests (part of integration tests) | mvn -Ptest clean verify | These are a subset of the integration tests that look at testing tDAR from the outside in (that is they interact with tDAR as a web browser only and attempt to test the freemarker and user interaction components of tDAR. These tests need to be run as a maven task specifically. Tests can be targeted by using the property: it.test=MyTestClassSimpleName. | All test class names should end with WebITCase. | No |
The maven test profile:
The maven test profile is used to configure maven to use /src/test/resources to look for additional properties and make sure that it runs properly. It runs in a clean crowd instance and ensures that jetty runs on a different port.
Running WebITCase tests against an alternate tDAR instance using JUnit
One of the drawbacks to running the web tests using verify goal is that you don't have visibility to the local jetty instance's log messages. You can get around this by running the web tests in JUnit, however, you'll first need to instruct the webtests to connect to a different server (since the test jetty instance will not be created). There are a couple ways to go about this...
Option 1 - Running the web tests against to a stand-alone instance of tDAR
- modify the following values in TestConstants.java
- DEFAULT_BASE_URL - e.g. "http://alpha.tdar.org:". Don't forget the colon.
- DEFAULT_PORT - e.g. "8080"
- USERNAME - change to a known account on the standalone instance.
- PASSWORD
- ADMIN_USERNAME - change to a known admin-level- account on the standalone instance
- ADMIN_PASSWORD
- Run the test using JUnit instead of via the maven verify goal
Option 2 - Running the web tests against a stand-alone test jetty instance
Similar to above, instead of modifying the test constants you modify the web app config to run a standalone instance of the test version of your web app.
- Modify /src/main/resources/hibernate.properties to specify the test database (i.e copy/paste the values from src/test/resources/hibernate.properties)
- Modify /src/main/resources/crowd.properties to specify the test authentication host
- Do one of the following (but not both)
- change jetty port in pom.xml from 8080 to 8180, -OR-
- change the DEAULT_PORT in TdarConstants.java to connect to 8080 instead of 8180.
Writing Tests in tDAR
Starting Points
Rebuilding the test database
src/main/db/tdarmetadata.zip is our sandbox populated database for local development and also used to generate the test database, e.g., src/main/db/init-test.sql
To rebuild init-test.sql after any changes to the tdarmetadata schema, follow these steps:
- drop your local development tdarmetadata database and recreate it from
tdarmetadata.zip - apply all schema changes in
src/main/db/upgrade-db.sql(remember to add schema changes to upgrade-db.sql first!) - run
mvn -PsqlExtract initialize compile exec:java this should rebuild
src/test/db/init-test.sqlbased onsrc/test/db/extractRecords.sqlextractRecords.sqlshould only need to be modified when there are significant changes to the schema (e.g., consolidating tables or other table-level changes, or adding new test data, new resource ids, etc.)