Overview

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

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 Module.getUnitTests() method.

Integration Tests

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 Module.getIntegrationTests() method.

Functional Tests

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.

Install Browser Driver

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.

• ChromeDriver is used to run tests on Google Chrome.
  • Specify location in webdriver.chrome.driver
• geckodriver is used to run tests on Firefox.
  • Specify location in webdriver.gecko.driver

Running Functional Tests

To run a functional test on a development machine where LabKey Server is running locally, there are a number of relevant Gradle tasks:

• ./gradlew :server:test:setPassword
  • Set login to be used by UI tests (adds an entry to your .netrc file)
• ./gradlew :server:test:uiTests
  • Displays a GUI to choose specific tests to run and set options

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
  • Run tests from specific test classes. In this case, BasicTest.
• ./gradlew :server:test:uiTests -Ptest=BasicTest.testCredits.testScripts,IssuesTest.emailTest
  • Run specific test methods.
• ./gradlew :server:test:uiTests -Psuite=DRT
  • Run all tests in a particular suite. In this case the DRTs.
• ./gradlew :server:test:uiTests -Psuite=DRT -Pselenium.browser=firefox
  • Run the DRTs on Firefox
• ./gradlew :server:test:uiTests -Psuite=BVT -Pexperimental.legacy-lineage=true
  • Runs the BVTs with the legacy-lineage experimental feature enabled.
• ./gradlew :server:test:uiTests -Ptest=LinePlotTest -Pclean=false
  • Disable post-test cleanup for passing tests in order to inspect the server state after a test.

Running Tests for an Individual Module

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.

Related Topics

• Contribute
• Writing Automated Tests