Performance von PHPUnit-Suites verbessern

1. Wo geht die Zeit wirklich verloren?

Bevor man optimiert, muss man messen. PHPUnit bietet mit dem Attribut #[Group('slow')] und dem --log-junit-Flag eine einfache Möglichkeit, die langsamsten Tests zu identifizieren. Die JUnit-XML-Ausgabe enthält für jeden Test die Laufzeit in Sekunden. Ein einfaches sort auf diesem Attribut zeigt sofort, welche Tests unverhältnismäßig lange dauern. Häufige Kandidaten: Tests, die echte HTTP-Anfragen absetzen, Tests mit vollständigem Datenbankschema-Setup, Tests mit schwerfälligem Bootstrap und Tests, die unnötig viele Fixture-Daten laden.

Ein zweiter Ansatz ist die Profiler-Integration. PHPUnit selbst hat keinen eingebauten Profiler, aber Blackfire und Xdebug können auch während des Test-Runs aktiv sein und zeigen, welche Methodenaufrufe die meiste Zeit verbrauchen. In der Praxis lässt sich das Ergebnis meist auf zwei bis drei Muster reduzieren: Der Bootstrap lädt zu viel, die Fixtures sind zu schwer, oder Coverage-Analyse mit Xdebug erzeugt prohibitiven Overhead. Jedes dieser Muster hat einen anderen Lösungsansatz.

2. pcov statt Xdebug: Coverage ohne Laufzeitstrafe

Xdebug ist der Standard für PHP-Debugging, aber als Coverage-Treiber ist es überproportional langsam. Bei aktiviertem Xdebug können PHPUnit-Tests drei- bis fünfmal langsamer laufen als ohne Coverage-Analyse. Der Grund: Xdebug instrumentiert jede einzelne PHP-Zeile zur Laufzeit, um Ausführungspfade zu erfassen. Für interaktives Debugging ist diese Granularität wertvoll; für Coverage-Analyse ist sie übermäßig.

pcov ist eine leichtgewichtige PHP-Extension, die ausschließlich Coverage-Daten sammelt – ohne Debugging-Features, ohne Variable-Inspektion, ohne Remote-Debugging-Protokoll. In Tests ist pcov typischerweise nur 20 bis 30 Prozent langsamer als ein Lauf ohne Coverage, während Xdebug das Drei- bis Fünffache kostet. Die Installation erfolgt über PECL oder über vorgefertigte Pakete in gängigen PHP-Containern. In der phpunit.xml wird pcov über <coverage driver="pcov"> aktiviert.

# Installation von pcov (PECL)
pecl install pcov

# Aktivierung in php.ini (nur für Test-Umgebung)
extension=pcov.so
pcov.enabled=1
pcov.directory=/var/www/html/src

# phpunit.xml — Coverage mit pcov konfigurieren
# <coverage driver="pcov">
#   <include>
#     <directory suffix=".php">src/app/code</directory>
#   </include>
#   <exclude>
#     <directory>src/app/code/Vendor/Module/Test</directory>
#   </exclude>
# </coverage>

# Laufzeit-Vergleich (typisch für mittelgroße Suite, 500 Tests):
# Ohne Coverage:   45 Sekunden
# Mit Xdebug:     180 Sekunden  (+300%)
# Mit pcov:        60 Sekunden  ( +33%)

# Umgebungsvariable für CI — Coverage nur bei Bedarf
PHPUNIT_COVERAGE=${PHPUNIT_COVERAGE:-0}
if [[ "$PHPUNIT_COVERAGE" == "1" ]]; then
  XDEBUG_MODE=off vendor/bin/phpunit --coverage-clover coverage.xml
else
  XDEBUG_MODE=off vendor/bin/phpunit
fi

Ein wichtiger Hinweis zur Coverage-Strategie: Coverage-Berichte in jedem CI-Lauf zu generieren verbraucht Zeit. Die empfohlene Praxis ist, Coverage nur in dedizierten nightly-Builds oder bei Merges in den Hauptbranch zu messen. In Feature-Branch-Builds reicht es, Tests ohne Coverage schnell zu validieren. Diese Trennung reduziert die wahrgenommene CI-Laufzeit für Entwickler erheblich.

3. Bootstrap-Optimierung: Initialisierungsaufwand reduzieren

Der Bootstrap-Prozess von PHPUnit – das PHP-Skript, das vor allen Tests ausgeführt wird – ist häufig der unsichtbare Laufzeitfresser. In Magento-Projekten initialisiert der Bootstrap den vollständigen Objekt-Manager, lädt alle Konfigurationen, registriert alle Module und stellt Datenbankverbindungen her. Das dauert mehrere Sekunden, wird aber nur einmal pro Test-Run ausgeführt, sodass es bei Unit-Tests kaum auffällt. Bei vielen kurzen Tests ist der Bootstrap-Anteil an der Gesamtlaufzeit gering; bei wenigen, langen Tests relativ gesehen bedeutsamer.

Für Unit-Tests ohne Magento-Abhängigkeiten sollte ein schlanker Bootstrap verwendet werden, der ausschließlich den Composer-Autoloader lädt. Das spart mehrere Sekunden pro Run und ist die einfachste Optimierung überhaupt. Separate phpunit.xml-Dateien für Unit- und Integrationstests ermöglichen unterschiedliche Bootstraps. Ein Unit-Test-Bootstrap benötigt nur require __DIR__ . '/../vendor/autoload.php'; – keine Datenbankverbindung, kein Objekt-Manager, kein Konfigurationsaufbau.

<?php
// tests/unit/bootstrap.php — Lightweight bootstrap for unit tests only
// No database, no object manager, no Magento initialization

declare(strict_types=1);

// Only the Composer autoloader — nothing else
require_once dirname(__DIR__, 2) . '/vendor/autoload.php';

// Optional: set timezone to avoid date-related warnings
date_default_timezone_set('UTC');

// Optional: increase memory limit for large test suites
ini_set('memory_limit', '512M');

echo "Unit test bootstrap loaded (no DB, no Magento DI)\n";

<!-- phpunit-unit.xml — Separate config for unit tests -->
<?xml version="1.0" encoding="UTF-8"?>
<phpunit
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:noNamespaceSchemaLocation="vendor/phpunit/phpunit/phpunit.xsd"
  bootstrap="tests/unit/bootstrap.php"
  colors="true"
  stopOnFailure="false"
  cacheDirectory=".phpunit.cache"
>
  <testsuites>
    <testsuite name="unit">
      <directory>src/app/code</directory>
      <exclude>src/app/code/Mironsoft/*/Test/Integration</exclude>
    </testsuite>
  </testsuites>
  <coverage driver="pcov">
    <include>
      <directory suffix=".php">src/app/code</directory>
    </include>
    <exclude>
      <directory>src/app/code/Mironsoft/*/Test</directory>
    </exclude>
  </coverage>
</phpunit>

4. Schlanke Fixtures: weniger Datenbank, mehr Geschwindigkeit

Schwere Datenbankfixtures sind einer der häufigsten Laufzeitfresser in Integrationstests. Wenn jeder Test das vollständige Produktkatalog-Fixture lädt, das tausend Produkte, hundert Kategorien und alle Attributkonfigurationen enthält, addiert sich die Setup-Zeit schnell zu mehreren Minuten. Die Lösung ist das Prinzip der minimalen Fixtures: Jeder Test lädt nur genau die Daten, die er für seine Assertion benötigt – nicht mehr.

Statt großer SQL-Dump-Fixtures empfehlen sich programmatische Factories, die gezielt einzelne Datensätze anlegen. Eine Factory für einen Testprodukt legt nur das Produkt an, das der Test benötigt, mit genau den Attributen, die relevant sind. Andere Attribute erhalten Standardwerte. Das reduziert den Datenbankaufwand pro Test von mehreren Sekunden auf Millisekunden. Die Transaktions-Rollback-Strategie ergänzt das: Nach jedem Test wird die Transaktion zurückgerollt statt die Datenbank zu truncaten, was Schreiboperationen auf Disk vermeidet.

5. Test-Splitting: Unit von Integration trennen

Der wirkungsvollste einzelne Schritt zur Laufzeitreduzierung ist die konsequente Trennung von Unit- und Integrationstests in separate Suiten mit separaten Konfigurationen. Unit-Tests haben keine externen Abhängigkeiten, laufen in Millisekunden und können mit hoher Parallelität ausgeführt werden. Integrationstests haben Datenbankzugriff, sind langsamer und erfordern mehr Setup. Wenn beide Typen in derselben Suite gemischt werden, zieht der langsamste Typ die Gesamtlaufzeit nach oben.

In der Praxis bedeutet Trennung: Eine phpunit-unit.xml mit schlankem Bootstrap für schnelle Validierung im Entwickleralltag (Laufzeit: unter 30 Sekunden). Eine phpunit-integration.xml für vollständige Validierung in der CI-Pipeline (Laufzeit: mehrere Minuten, dafür vollständig). Entwickler führen lokal nur Unit-Tests aus, bevor sie committen. Die CI-Pipeline führt beide Suiten aus, Integration in einem dedizierten Job mit mehr Ressourcen.

6. Mocks strategisch einsetzen statt echte Dienste aufrufen

Jeder externe Dienst, den ein Test aufruft – HTTP-API, E-Mail-Server, Redis, Elasticsearch – fügt Latenz und Instabilität hinzu. Tests, die echte HTTP-Anfragen absetzen, sind mindestens um die Netzwerk-Roundtrip-Zeit langsamer als Tests mit Mock-Objekten. In einem Test mit fünf HTTP-Aufrufen à 100ms addiert sich das zu einer halben Sekunde Wartezeit – multipliziert mit hundert Tests sind das fast eine Minute, die durch Mocks eliminierbar wäre.

PHPUnit bietet mit createMock() und createStub() einfache Wege, externe Dienste durch schnelle In-Memory-Implementierungen zu ersetzen. Die Entscheidung, was gemockt wird und was nicht, orientiert sich an der Testpyramide: Unit-Tests mocken alles außer dem zu testenden System. Integrationstests verwenden echte Datenbankverbindungen, aber gemockte externe HTTP-APIs. End-to-End-Tests verwenden reale Dienste, laufen aber selten und in separaten Umgebungen.

7. paratest für die letzten Gewinne

Nachdem Bootstrap, Coverage-Treiber und Fixtures optimiert sind, ist paratest der letzte Hebel für weitere Laufzeitreduktion. Bei sauber isolierten Unit-Tests, die keinen geteilten Zustand haben, skaliert paratest nahezu linear mit der Prozessanzahl. Vier Prozesse auf einem Vierkernsystem bringen die Unit-Test-Suite von 40 Sekunden auf etwa 12 Sekunden – eine Reduktion um 70 Prozent, die ohne jede Codeänderung erreichbar ist.

Der PHPUnit-Cache (.phpunit.cache/) speichert zwischen Runs, welche Tests fehlgeschlagen sind, und führt diese beim nächsten Lauf zuerst aus. Das Attribut defects für die Testausführungsreihenfolge (executionOrder="defects" in phpunit.xml) aktiviert dieses Verhalten. Entwickler sehen Feedback zu kürzlich fehlgeschlagenen Tests sofort – ohne auf das Ende der gesamten Suite zu warten. Kombiniert mit paratest verkürzt sich die subjektive Wartezeit nochmals deutlich.

<!-- phpunit.xml — Performance-optimierte Konfiguration -->
<?xml version="1.0" encoding="UTF-8"?>
<phpunit
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:noNamespaceSchemaLocation="vendor/phpunit/phpunit/phpunit.xsd"
  bootstrap="tests/unit/bootstrap.php"
  colors="true"
  cacheDirectory=".phpunit.cache"
  executionOrder="defects,duration"
  failOnRisky="true"
  failOnWarning="true"
>
  <!-- Run recently failed tests first, then shortest tests -->
  <!-- cacheDirectory persists between runs — commit to .gitignore -->

  <testsuites>
    <testsuite name="unit">
      <directory>src/app/code/Mironsoft</directory>
      <exclude>src/app/code/Mironsoft/*/Test/Integration</exclude>
    </testsuite>
  </testsuites>

  <!-- No coverage in default run — enable explicitly with --coverage-* flags -->
</phpunit>

9. Zusammenfassung

Die Performance von PHPUnit-Suites verbessert sich durch gezielte Maßnahmen, nicht durch blindes Optimieren. Die Diagnose-Phase – Messen statt Raten – identifiziert zuerst die größten Zeitfresser. Coverage mit Xdebug ist fast immer der erste Kandidat; der Wechsel zu pcov bringt sofort messbare Gewinne ohne jede Codeänderung. Die Trennung von Unit- und Integrationstests in separate Suiten mit unterschiedlichen Bootstraps ist der strukturell wichtigste Schritt, weil sie Entwicklern schnelles lokales Feedback zurückgibt.

Schlanke Fixtures und programmatische Factories eliminieren den Overhead schwerer Datenbankoperationen. Mocks ersetzen langsame externe Dienste in Unit-Tests. paratest nutzt verfügbare CPU-Kerne und reduziert die Gesamtlaufzeit nochmals. Der PHPUnit-Cache führt zuletzt fehlgeschlagene Tests zuerst aus und gibt Entwicklern schneller Rückmeldung. Diese Kombination bringt typische Suiten von zwanzig Minuten auf drei bis fünf Minuten – ohne dass ein einziger Test entfernt oder ein Qualitätskompromiss eingegangen werden muss.