Testing and continuous integration #

This page is for developers who change Exponential and want to know which tests and checks will run, and for administrators who want to judge how a release was verified. It answers: which test framework and suites exist, what runs on every push and pull request, what runs only locally, and what is not covered. The working details are in Quality checks and Continuous integration.

Summary #

PHPUnit #

What it is. PHPUnit (Sebastian Bergmann) is the standard unit testing framework for PHP.

Version. composer.json require-dev allows phpunit/phpunit ^9.6 || ^10.5 || ^11.5 || ^12.0 || ^13.4, so Composer picks the newest one the PHP version allows. CI pins it per leg: PHPUnit 10.5 on PHP 8.1, 11.5 on PHP 8.2 and 8.3, the composer.json range (13) on PHP 8.4 and 8.5. phpunit.xml references the PHPUnit 13.0 schema.

Configuration (phpunit.xml):

• bootstrap="tests/bootstrap.php": loads Composer's autoloader, enables the test class map (ezpAutoloader::enableTests(), var/autoload/ezp_tests.php), defines PHPUNIT_COMPOSER_INSTALL for isolated child processes and loads the toolkit classes in tests/toolkit/ (ezpTestCase, ezpDatabaseTestCase ...). It does not boot the kernel; tests that need it do so themselves.
• memory_limit 1G, environment EZP_TEST_ENVIRONMENT=1, <source> = lib and kernel.
• Groups excluded by default: database, mail-live, mongodb-live, network-live.

Suites (23, from phpunit.xml):

Counts (made for this page with find):

43 test files are tagged @group database. Quality checks speaks of more than 10,000 test methods in the whole run; that figure was not recounted here.

Tests with and without a database #

• vendor/bin/phpunit runs every suite without a database; the database group is excluded.
• tests/runtests.php --dsn <dsn> --db-per-test runs every suite of phpunit.xml, with its excludes, against a throwaway database, as CI's phpunit-db job does. It exits with PHPUnit's code (since 2026-10-15; before, it always exited with 0).
• Live-installation suites skip each class with a reason when no installed site is present (CI has none).

GitHub Actions workflows #

What it is. GitHub Actions runs the workflows in .github/workflows/ on GitHub-hosted Ubuntu runners.

Common properties, all read from the workflow files:

• permissions: contents: read (actions: read for CI health); no pull_request_target. tests/tests/bin/CiWorkflowPullRequestTest.php keeps it that way.
• COMPOSER_ROOT_VERSION: dev-main so packages requiring se7enxweb/exponential resolve on a pull request.
• One concurrency group per pull request (a new push cancels the old run); each push to main keeps its own run.
• Every job has a timeout (20 or 30 minutes); Composer steps retry three times.
• The PHPUnit jobs resolve dependencies fresh on every run (composer.ci-phpunit.json, not committed), so a new dependency release can change a result without a change in the repository.
• phpunit checks that the suites security, kernel-classes, lib, expservices and ezoe are configured.

The file manifest #

What it is. share/filelist.md5 lists md5 path for every file of the distribution (9,551 lines). The administration's upgrade check compares the installed files against it; a stale line shows up there as a modified file. See File consistency check.

• bin/php/checkmanifest.php --all checks every entry, --staged the staged files, --fix rewrites stale checksums and adds missing files. It needs no kernel and no database, and uses the same class as the upgrade check (kernel/private/classes/expfileconsistencyreport.php).
• make manifest-check and make manifest-fix wrap it.
• Pre-commit hook: --staged. CI: blocking on a push to main, a warning with the exact patch on a pull request.

Status: Complies.

Git hooks #

make hooks sets git config core.hooksPath .githooks. The hooks are opt-in per clone.

.githooks/check-commit-range [--github] <base> <head> applies the commit message rule to a range, as CI does. A commit by a project author (an address listed in .githooks/commit-msg-authors) fails on a bad subject; a contributor's commit only gets a warning, because pull requests are merged with their commits as written. EXP_COMMIT_MSG_STRICT_ALL=1 makes every author strict. Tested by tests/tests/bin/githooks/CheckCommitRangeTest.php.

The gates before a push #

The project's push gate runs the CI checks on a committed revision in a clean worktree (Continuous integration, "The local gates and CI"):

The gate script itself is a maintainer tool and is not part of the repository; the commands it runs are the ones in the table, all of which are in the repository. For contributors, Quality checks, "Before you push", lists the same checks as plain commands.

Running only the tests of a change: tests/test-map.json #

tests/test-map.json maps source files to the test files that cover them. It has three sections: map (hand-made entries, a path or a pattern where * also matches /), generated (source paths that test files name literally) and ignore (files no PHPUnit test covers on purpose: doc/*, *.md, share/filelist.md5, translations, autoload/*, .github/* ...). Combined with tests named after the changed classes, it selects the test files of a change; each is run in its own PHPUnit process. The commands are in Quality checks, "Run only the tests of a change".

Known gaps #

1. Six test files are in no suite and therefore never run by phpunit or CI: tests/tests/extension/ezupdate/ezUpdateComposerLocationTest.php, ezUpdateComposerVersionCacheTest.php, ezUpdateInstallabilityTest.php, ezUpdateJobOutcomeTest.php, tests/tests/extension/bccie/ezBccieTest.php and tests/tests/extension/syndication/ezSyndicationTest.php (checked against the suites of phpunit.xml).
2. The live-installation suites (expservices, ezoe, cjw_newsletter, explayouts_admin, mongodb-live) are skipped in CI.
3. Database jobs cover MySQL 8.0 and PostgreSQL 15 only; SQLite 3 (the default database), MariaDB, Oracle and MongoDB servers have no CI job.
4. PHPUnit does not run on PHP 8.0.
5. Coverage is collected on the DB-less legs but neither published nor enforced.
6. Code style and performance are warnings only.
7. Git hooks are opt-in; a clone without make hooks relies on CI.
8. Branch protection: main has no branch protection rule or ruleset (GitHub API, 2026-10-18), so a red check does not technically block a merge or push; it is a policy.

Related pages #

• Quality checks
• Continuous integration
• Coding standards
• Source control and releases
• PHP, PHP-FIG and Composer standards