The LabKey Server code base includes extensive automated tests. These, combined with hands-on testing, ensure that the software continues to work reliably. There are three major categories of automated tests.
Unit tests exercise a single unit of code, typically contained within a single Java class. They do not assume that they run inside of any particular execution context. They are written using the JUnit test framework. Unit tests can be run directly through IntelliJ by right clicking on the test class or a single test method (identified with an
@Test annotation) and selecting Run or Debug. They can also be run through the web application, as described below for integration tests. Unit tests are registered at runtime via the
Integration tests exercise functionality that combines multiple units of code. They do not exercise the end-user interface. Integration tests are implemented using the JUnit test framework, like unit tests. They generally assume that they are running in a full web server execution context, where they have access to database connections and other resources. They can be invoked through the web application by going to
http://localhost:8080/labkey/junit-begin.view or its equivalent URL (based on the server, port, and context path). Integration tests are registered at runtime via the
Functional tests exercise the full application functionality, typically from the perspective of an end-user or simulated client application. Most functional tests use the Selenium test framework to drive a web browser in the same way that an end user would interact with LabKey Server. Unlike unit and integration tests, functional tests treat the server as a black-box. They run independently and are built independently of LabKey Server (though some of them share source code repositories).
Functional tests are organized into various test suites, including the Developer Regression Tests (DRT), Build Verification Tests (BVT), Daily suites, and numerous module-specific suites. LabKey's Continuous Integration system runs these suites at varying frequencies in response to code changes.
After setting up your development machine, you should have the core test repository cloned to
server/testAutomation. As a convenience, this repository contains executables for running Selenium tests on Chrome and Firefox but they may not be compatible with the browser version you have installed.
If, when you attempt to run tests, there is an error indicating a problem launching the browser, you might need to install drivers manually. If you do, you should add a property -- specified below -- to
testAutomation/test.properties that points to the driver executable.
To run a functional test on a development machine where LabKey Server is running locally, there are a number of relevant Gradle tasks:
You can specify various properties to customize test execution. These properties are defined in
server/testAutomation/test.properties and can be overridden by modifying that file or adding
-Pprop=value to your command:
./gradlew :server:test:uiTests -Ptest=basic
./gradlew :server:test:uiTests -Ptest=BasicTest.testCredits.testScripts,IssuesTest.emailTest
./gradlew :server:test:uiTests -Psuite=DRT
./gradlew :server:test:uiTests -Psuite=DRT -Pselenium.browser=firefox
./gradlew :server:test:uiTests -Psuite=BVT -Pexperimental.legacy-lineage=true
legacy-lineageexperimental feature enabled.
./gradlew :server:test:uiTests -Ptest=LinePlotTest -Pclean=false
Many modules define a test suite that can be run using the
suite parameter. (e.g.
./gradlew :server:test:uiTests -Psuite=targetedms). Alternatively, you can run tests based on their source code location.
Gradle brings with it the ability to do very targeted builds and tasks, thus we have the ability to run the tests for a particular module without using the test runner project.
Until we resolve the issue of making the test runner able to run tests from all modules while still allowing the individual tests to be run, you must set the project property
enableUiTests in order to be able to run the tests for an individual module.
For any module that has its own
test/src directory, there will be a
moduleUiTests task so you can run only the tests for only that module. For example, you can run the tests for MS2 by using this command:
gradlew -PenableUiTests :server:modules:ms2:moduleUiTests
Note: It is still required that you have the
:server:testAutomation project since that is the location of the
test.properties file and the helper methods for running tests.