Tests und Continuous Integration #

Diese Seite richtet sich an Entwickler, die Exponential ändern und wissen möchten, welche Tests und Prüfungen laufen, und an Administratoren, die beurteilen möchten, wie ein Release überprüft wurde. Sie beantwortet: Welches Testframework und welche Suites es gibt, was bei jedem Push und Pull Request läuft, was nur lokal läuft und was nicht abgedeckt ist. Die Einzelheiten der Arbeit stehen unter Qualitätsprüfungen und Continuous Integration.

Zusammenfassung #

PHPUnit #

Was es ist. PHPUnit (Sebastian Bergmann) ist das Standard-Framework für Unit-Tests in PHP.

Version. require-dev in composer.json erlaubt phpunit/phpunit ^9.6 || ^10.5 || ^11.5 || ^12.0 || ^13.4, sodass Composer die neueste Version wählt, die die PHP-Version zulässt. Die CI legt sie je Durchlauf fest: PHPUnit 10.5 unter PHP 8.1, 11.5 unter PHP 8.2 und 8.3, den Bereich aus composer.json (13) unter PHP 8.4 und 8.5. phpunit.xml verweist auf das Schema von PHPUnit 13.0.

Konfiguration (phpunit.xml):

• bootstrap="tests/bootstrap.php": lädt den Autoloader von Composer, aktiviert die Klassenzuordnung der Tests (ezpAutoloader::enableTests(), var/autoload/ezp_tests.php), definiert PHPUNIT_COMPOSER_INSTALL für isolierte Kindprozesse und lädt die Toolkit-Klassen in tests/toolkit/ (ezpTestCase, ezpDatabaseTestCase ...). Den Kernel startet es nicht; Tests, die ihn brauchen, tun das selbst.
• memory_limit 1G, Umgebung EZP_TEST_ENVIRONMENT=1, <source> = lib und kernel.
• Standardmäßig ausgeschlossene Gruppen: database, mail-live, mongodb-live, network-live.

Suites (23, aus phpunit.xml):

Zahlen (für diese Seite mit find ermittelt):

43 Testdateien tragen @group database. Qualitätsprüfungen nennt mehr als 10.000 Testmethoden im gesamten Durchlauf; diese Zahl wurde hier nicht nachgezählt.

Tests mit und ohne Datenbank #

• vendor/bin/phpunit führt jede Suite ohne Datenbank aus; die Gruppe database ist ausgeschlossen.
• tests/runtests.php --dsn <dsn> --db-per-test führt jede Suite aus phpunit.xml mit ihren Ausschlüssen gegen eine Wegwerf-Datenbank aus, wie es der CI-Job phpunit-db tut. Es endet mit dem Exit-Code von PHPUnit (seit 15.10.2026; vorher endete es immer mit 0).
• Suites für laufende Installationen überspringen jede Klasse mit einer Begründung, wenn keine installierte Site vorhanden ist (die CI hat keine).

Workflows von GitHub Actions #

Was es ist. GitHub Actions führt die Workflows in .github/workflows/ auf von GitHub gehosteten Ubuntu-Runnern aus.

Gemeinsame Eigenschaften, alle aus den Workflow-Dateien gelesen:

• permissions: contents: read (actions: read für CI health); kein pull_request_target. tests/tests/bin/CiWorkflowPullRequestTest.php sorgt dafür, dass das so bleibt.
• COMPOSER_ROOT_VERSION: dev-main, damit Pakete, die se7enxweb/exponential voraussetzen, bei einem Pull Request aufgelöst werden.
• Eine Concurrency-Gruppe je Pull Request (ein neuer Push bricht den alten Durchlauf ab); jeder Push auf main behält seinen eigenen Durchlauf.
• Jeder Job hat ein Zeitlimit (20 oder 30 Minuten); Composer-Schritte werden dreimal wiederholt.
• Die PHPUnit-Jobs lösen die Abhängigkeiten bei jedem Durchlauf neu auf (composer.ci-phpunit.json, nicht committet), sodass ein neues Release einer Abhängigkeit ein Ergebnis ändern kann, ohne dass sich das Repository ändert.
• phpunit prüft, dass die Suites security, kernel-classes, lib, expservices und ezoe konfiguriert sind.

Das Dateimanifest #

Was es ist. share/filelist.md5 listet md5 path für jede Datei der Distribution (9.551 Zeilen). Die Aktualisierungsprüfung der Administrationsoberfläche vergleicht die installierten Dateien damit; eine veraltete Zeile erscheint dort als geänderte Datei. Siehe Prüfung der Dateikonsistenz.

• bin/php/checkmanifest.php --all prüft jeden Eintrag, --staged die vorgemerkten Dateien, --fix schreibt veraltete Prüfsummen neu und ergänzt fehlende Dateien. Es braucht weder Kernel noch Datenbank und verwendet dieselbe Klasse wie die Aktualisierungsprüfung (kernel/private/classes/expfileconsistencyreport.php).
• make manifest-check und make manifest-fix kapseln es.
• Pre-Commit-Hook: --staged. CI: blockierend bei einem Push auf main, bei einem Pull Request eine Warnung mit dem genauen Patch.

Status: Erfüllt.

Git-Hooks #

make hooks setzt git config core.hooksPath .githooks. Die Hooks sind je Klon ein Opt-in.

.githooks/check-commit-range [--github] <base> <head> wendet die Regel für Commit-Nachrichten auf einen Bereich an, wie es die CI tut. Ein Commit eines Projektautors (eine Adresse, die in .githooks/commit-msg-authors aufgeführt ist) scheitert an einem fehlerhaften Betreff; der Commit eines Beitragenden erhält nur eine Warnung, weil Pull Requests mit ihren Commits so zusammengeführt werden, wie sie geschrieben sind. EXP_COMMIT_MSG_STRICT_ALL=1 macht die Prüfung für jeden Autor streng. Getestet durch tests/tests/bin/githooks/CheckCommitRangeTest.php.

Die Prüfungen vor einem Push #

Die Push-Prüfung des Projekts führt die CI-Prüfungen für eine committete Revision in einem sauberen Worktree aus (Continuous Integration, „Die lokalen Prüfungen und die CI“):

Das Prüfskript selbst ist ein Werkzeug der Maintainer und nicht Teil des Repositorys; die Befehle, die es ausführt, sind die aus der Tabelle, und sie liegen alle im Repository. Für Beitragende listet Qualitätsprüfungen, „Vor dem Push“, dieselben Prüfungen als einfache Befehle auf.

Nur die Tests einer Änderung ausführen: tests/test-map.json #

tests/test-map.json ordnet Quelldateien den Testdateien zu, die sie abdecken. Sie hat drei Abschnitte: map (von Hand erstellte Einträge, ein Pfad oder ein Muster, in dem * auch / abdeckt), generated (Quellpfade, die Testdateien wörtlich nennen) und ignore (Dateien, die absichtlich kein PHPUnit-Test abdeckt: doc/*, *.md, share/filelist.md5, Übersetzungen, autoload/*, .github/* ...). Zusammen mit Tests, die nach den geänderten Klassen benannt sind, wählt sie die Testdateien einer Änderung aus; jede läuft in einem eigenen PHPUnit-Prozess. Die Befehle stehen unter Qualitätsprüfungen, „Nur die Tests einer Änderung ausführen“.

Bekannte Lücken #

1. Sechs Testdateien gehören zu keiner Suite und werden daher weder von phpunit noch von der CI ausgeführt: tests/tests/extension/ezupdate/ezUpdateComposerLocationTest.php, ezUpdateComposerVersionCacheTest.php, ezUpdateInstallabilityTest.php, ezUpdateJobOutcomeTest.php, tests/tests/extension/bccie/ezBccieTest.php und tests/tests/extension/syndication/ezSyndicationTest.php (gegen die Suites in phpunit.xml geprüft).
2. Die Suites für laufende Installationen (expservices, ezoe, cjw_newsletter, explayouts_admin, mongodb-live) werden in der CI übersprungen.
3. Die Datenbank-Jobs decken nur MySQL 8.0 und PostgreSQL 15 ab; SQLite 3 (die Standarddatenbank), MariaDB, Oracle und MongoDB-Server haben keinen CI-Job.
4. PHPUnit läuft nicht unter PHP 8.0.
5. Die Abdeckung wird in den Durchläufen ohne Datenbank erfasst, aber weder veröffentlicht noch erzwungen.
6. Codestil und Leistung sind nur Warnungen.
7. Git-Hooks sind ein Opt-in; ein Klon ohne make hooks verlässt sich auf die CI.
8. Branch-Schutz: main hat keine Branch-Schutzregel und kein Ruleset (GitHub-API, 18.10.2026), daher blockiert eine rote Prüfung einen Merge oder Push technisch nicht; es handelt sich um eine Richtlinie.

Verwandte Seiten #

• Qualitätsprüfungen
• Continuous Integration
• Codierstandards
• Versionsverwaltung und Releases
• Standards für PHP, PHP-FIG und Composer