Update and Perform a Clean Build

Before you run any tests, follow these steps to ensure that you are able to build with the latest sources:

1. Stop your development instance of Tomcat if it is running.
2. From a command prompt, navigate to <labkey-home>/server
3. Run the gradlew cleanBuild build task to delete existing build information.
4. From your <labkey-home> directory (the root directory of your LabKey Server enlistment), use the svn update command to update your enlistment with the latest changes made by other developers.
5. Verify that any merged files have merged correctly.
6. Resolve any conflicts within files that have been modified both by you and by another developer.
7. Run the gradlew deployApp target to build the latest sources from scratch.

Run the Test Suite(s)

LabKey maintains automated tests that verify most areas of the product. These tests use the Selenium Remote Control test harness to exercise and verify server functionality by automating the browser. LabKey develops and runs all tests using the most recent versions of Chrome and Firefox supported by Selenium, which usually lags the most recent public browser release. Thus, Firefox's Extended Support Release (ESR) is typically a good option to use. Other versions of Firefox have not been tested and are not recommended. You can have multiple versions of Firefox installed, as long as you specify the path to Firefox when you run the tests. For example:

gradlew :server:test:uiTest -Psuite=DRT -Pselenium.browser.path="c:\Program Files\Mozilla Firefox\firefox.exe"

LabKey currently maintains three test suites:

• Developer Regression Test (DRT): a quick (< 10 minutes) suite that developers run before every commit that touches core server code
• Build Verification Test (BVT): a longer (up to an hour) suite that our TeamCity-based server farm runs automatically after every commit
• Daily Test: an additional suite of tests that TeamCity runs once a night

If you modify only custom modules, you should run their corresponding automated tests, as well as the JUnitTest which runs a variety of unit and integration tests, including DB schema validation.

To run the DRT, follow these steps:

1. Start your development instance of Tomcat.
2. From a command prompt, navigate to <labkey-home>/server/test
3. Run the gradlew :server:test:uiTest -Psuite=DRT task. (Add -PhaltOnError=false to continue running if a test fails.)
4. When prompted, enter the user name and password for an administrator account on your local development installation of LabKey Server.

• gradlew :server:test:uiTest -Psuite=DRT: Compile and run the DRT suite
• gradlew :server:test:uiTest -Psuite=BVT: Compile and run the BVT suite
• gradlew :server:test:uiTest -Psuite=daily: Compile and run the daily suite
• gradlew :server:test:uiTest -Ptest=JUnitTest: Compile and run just the JUnitTest
• gradlew :server:test setPassword: Change your saved password. This target sets your login information in .cpasDRTPassword in your home directory.
• gradlew :server:test tasks: Display instructions and additional options

Test Failures

If a test fails, you'll see error information output to the command prompt, including the nature of the error, the point in the test where it occurred, and the name of an HTML file and a PNG file, written to the <labkey-home>/server/test/build/logs directory, which can be viewed to see the state of the browser at the time the test failed.

A helpful resource: Java Testing Tips

Modifying the Test Suites

You can add to or modify existing tests and create new tests. To build your changes, use the gradlew deployApp target. You can also set up a run/debug configuration in IntelliJ to build and debug changes to the DRT.

To edit an existing test, locate the test class beneath the <labkey-home>/server/test/src directory.

To create a new test, extend the BaseSeleniumWebTest class, and add the name of your new class to the TestSet enum in TestSet.java.

Make sure that you carefully test any changes you make to the tests before checking them in.

Checking In Code Changes

Once you pass the tests successfully, you can check in your code. Make sure that you have updated your enlistment to include any recent changes checked in by other developers. To determine which files to check in, use the svn commit command. This command displays a list of the files that you have modified, which you can compare to the repository version. Be sure to provide a log message with your check-in so that other developers can easily ascertain what you have changed. An automated email describing your check-in is immediately sent to all who have access to the LabKey Server source project.

After you check in, TeamCity will build the complete sources and run the full BVT on all of the supported databases as an independent verification. You'll receive another email from the automated system letting you know whether the independent verification passed or failed. We request that you remain available by email from the time you check in until you receive the email confirming that the automated build and test suite has passed successfully, so that if there is a problem with your check-in, you can revert your change or check in a fix and minimize the amount of time that others are blocked.

If the automated test suite fails, all developers must halt check-ins until the problem is remedied and the test suite runs successfully. At that time the tree is once again open for check-ins.

Related Topics

• Running Automated Tests