Continuous Integration: Tests automatisiert laufen lassen

~7 Min. Lesezeit Zuletzt aktualisiert am 9. August 2026

Jeder in Kapitel 91-94 gezeigte Testbefehl ist nur so viel wert, wie er tatsächlich ausgeführt wird. Ein Unit Test, den niemand vor dem Merge laufen lässt, entdeckt eine Regression frühestens dann, wenn sie bereits im Hauptzweig gelandet ist. Eine CI-Pipeline schließt genau diese Lücke: sie führt dieselben Befehle automatisch bei jedem Push und jeder Merge Request aus.

Zwei Geschwindigkeiten, zwei Jobs

Kapitel 93 hat den Geschwindigkeitsunterschied zwischen Unit- und Integrationstests bereits erklärt - dieselbe Trennung gehört in die Pipeline. Ein schneller unit-tests-Job läuft bei jedem einzelnen Push, ein langsamerer integration-tests-Job (mit eigener Datenbank als GitLab-CI-Service) nur bei Merge Requests gegen den Hauptzweig - so bleibt die Feedback-Schleife für den alltäglichen Commit kurz.

.gitlab-ci.yml

stages:
  - static-analysis
  - test

variables:
  COMPOSER_CACHE_DIR: "$CI_PROJECT_DIR/.composer-cache"

cache:
  key: composer-cache
  paths:
    - .composer-cache/

phpstan:
  stage: static-analysis
  image: mark0x/php-8.4-fpm:latest
  script:
    - composer install --prefer-dist --no-progress
    - vendor/bin/phpstan analyse app/code/Mironsoft/Loyalty --level=5 --no-progress

phpcs:
  stage: static-analysis
  image: mark0x/php-8.4-fpm:latest
  script:
    - composer install --prefer-dist --no-progress
    - vendor/bin/phpcs --standard=Magento2 app/code/Mironsoft/Loyalty

unit-tests:
  stage: test
  image: mark0x/php-8.4-fpm:latest
  script:
    - composer install --prefer-dist --no-progress
    - vendor/bin/phpunit -c dev/tests/unit/phpunit.xml.dist \
        --coverage-text --colors=never \
        app/code/Mironsoft/Loyalty/Test/Unit
  rules:
    - if: '$CI_PIPELINE_SOURCE == "push" || $CI_PIPELINE_SOURCE == "merge_request_event"'

integration-tests:
  stage: test
  image: mark0x/php-8.4-fpm:latest
  services:
    - name: mysql:8.0
      alias: db
  variables:
    MYSQL_ROOT_PASSWORD: magento
    MYSQL_DATABASE: magento_integration_tests
  script:
    - composer install --prefer-dist --no-progress
    - cp dev/tests/integration/etc/install-config-mysql.php.dist \
        dev/tests/integration/etc/install-config-mysql.php
    - vendor/bin/phpunit -c dev/tests/integration/phpunit.xml.dist \
        app/code/Mironsoft/Loyalty/Test/Integration
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'

Tipp: Der services-Eintrag auf integration-tests startet einen eigenen, isolierten MySQL-Container nur für diesen Job - exakt dasselbe Prinzip wie compose.dev.yaml in diesem Projekt, nur für die CI-Pipeline statt für die lokale Entwicklungsumgebung.

Statische Analyse vor den Tests

phpstan und phpcs laufen als eigene Stage vor test - ein Modul mit einem PHPStan-Fehler auf Level 5 muss nicht erst die deutlich langsamere Testsuite durchlaufen, um zu scheitern. Kapitel 96 vertieft genau diesen phpstan-Job.

Achtung: Ein rot fehlschlagender integration-tests-Job, der ignoriert wird, weil "die Datenbank in CI eh immer mal wieder zickt", ist gefährlicher als gar kein Integrationstest - er erzeugt eine trügerische Sicherheit, während echte Regressionen im Rauschen untergehen. Ein instabiler CI-Job gehört repariert oder entfernt, nie stillschweigend ignoriert.

Kapitel 96 schließt Block 11 - und den phpstan-Job aus der Pipeline oben - mit einem genaueren Blick auf PHPStan Level 5 in genau diesem Modul ab.

Vorheriges Kapitel Testabdeckung sinnvoll priorisieren (keine 100-%-Dogmatik) Nächstes Kapitel PHPStan und Codequalität im eigenen Modul sicherstellen