From Request Tracker Wiki
Revision as of 18:05, 17 December 2021 by Brett (talk | contribs) (add docs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Test Prerequisites

The best way to set up RT for running tests (both its own and extensions') is by running the following from a source checkout:

./ --with-db-type=TYPE --enable-layout=inplace [other options ...]
mkdir -p var

Then make sure all your dependencies are in place by running make testdeps. (If you need help with that part, check out ManualInstallation.) If you're at that point and just want to get running as fast as possible, skip down to "Environment Variables to Control Tests." The next couple of sections give more background about what's going on.

Why a real database?

RT does include database-specific tests to check that various integrations work as expected. There's no good way to abstract these, so the test suite selects and runs the tests appropriate for your database.

Why an inplace layout?

The RT tests read the configuration file located in the directory named at $RT::Generated::EtcPath. If you use the default relative layout, or another layout intended for production like FHS, the tests will try to read your production configuration. That's probably not what you want.

Note that the tests only read They do not read or files under RT_SiteConfig.d. You cannot change the behavior of tests by editing configuration there.

(This is another reason you need to specify a database type on the configure line: so it gets put into There are environment variables to control most database parameters you need, but not the database type.)

Environment Variables to Control Tests

Test RT Configuration

Except on SQLite, the tests need permission to create new databases; to create new users in the database; and to grant rights to those users. To run the tests at all, you must set the environment variables RT_DBA_USER and RT_DBA_PASSWORD with the username and password, respectively, of a database account that has all those rights.

The tests write a small it uses to configure itself. You can control some of the settings with environment variables. Refer to the RT_Config documentation for full details.

Environment variable Corresponding RT_SiteConfig setting
RT_TEST_DB_SID $DatabaseName (intended for Oracle only)
RT_TEST_DB_HOST $DatabaseHost
RT_TEST_PLUGINS @Plugins (split on spaces)

Test Selection

A few tests are skipped unless you do/n't set an environment variable.

Environment variable Controls tests
RT_TEST_HEAVY Set a string here to run tests that require relatively expensive database queries.
RT_TEST_SMIME_REVOCATION Set a string here to run SMIME revocation tests. Doing so downloads a certificate revocation list (CRL) from the public Internet.
SKIP_GPG_TESTS Set a string here to skip tests that run GnuPG

Test Run Environment

Environment variable Controls tests
RTHOME Path to the RT source code checkout you use for testing. The core RT tests don't use this, but extensions usually do.
RT_TEST_PARALLEL Set a string here to notify the test suite that you're running tests in parallel. This changes some of the logic around database creation and elsewhere to avoid contention. You can set this even if you only have a single test runner.

You may also find some references to RT_TEST_PARALLEL_NUM. This is used by RT's Makefile to control how many test runners run in parallel. If you don't go through RT's Makefile, then nothing else uses that variable.

RT_TEST_APACHE Path to the httpd executable on your system
RT_TEST_APXS Path to the apxs executable on your system
RT_TEST_APACHE_MODULES Path to the directory where your httpd module .so files live

Running the Tests

Once you've set and exported all the environment variables you need, run the tests with prove from your source directory:

RT_TEST_PARALLEL=1 prove -w --lib --recurse --jobs=NUMBER t
Option Purpose
-w Enable warnings
--lib Load libraries from the lib directory (i.e., your source checkout)
--recurse Recurse through the path argument(s) to find and run all test .t files
--jobs=NUMBER Run NUMBER test runners in parallel
t Run tests under this path. You can specify other directories (some extensions have tests in xt), specific subdirectories, or even individual files.