Automatisiertes Testen in der Pipeline

Eine CI/CD-Pipeline ohne automatisierte Tests ist wie ein Auto ohne Bremsen: solange alles glatt läuft, geht's gut. Aber sobald ein Bug schneller deployed wird als ein Mensch reagieren kann, hast du Production-Probleme. Tests sind die Sicherheitslinie die verhindert, dass kaputter Code in Produktion landet.

Diese Lektion zeigt die wichtigsten Testtypen (Unit, Integration, E2E), das Test-Pyramide-Modell, Code-Coverage, sowie wie du Tests in GitHub Actions, GitLab CI und Jenkins integrierst. Pflicht-Wissen für jeden FIAE.

1) Die Test-Pyramide

Mike Cohn hat das Konzept der Test-Pyramide populär gemacht: ein Modell, das aussagt wie viele Tests welcher Sorte du brauchst. Die Idee: viele schnelle, isolierte Unit-Tests unten, weniger Integration-Tests in der Mitte, ganz wenige End-to-End-Tests oben:

Die klassische Test-Pyramide

E2E Tests
~5%

Integration Tests
~15-20%

Unit Tests
~75-80%

Klick eine Schicht

Klick eine Schicht der Pyramide für Erklärung was sie macht.

Anti-Pattern: Eistüte (Ice Cream Cone) – viele langsame UI-Tests, kaum Unit-Tests. Führt zu langen Pipeline-Laufzeiten und schwer zu debuggenden Fehlschlägen. Anti-Pattern Sanduhr: viel Unit + viel E2E, keine Integration – Bugs zwischen Modulen werden nicht gefunden.

2) Unit-Tests: das Fundament

Unit-Tests prüfen einzelne Funktionen oder Methoden isoliert von der Außenwelt. Klassische Eigenschaften: schnell, deterministisch, unabhängig. Beispiel in Python mit pytest:

test_calculator.pyPython (pytest)

1from calculator import add, divide
2import pytest
3
4def test_add_positive_numbers():
5    assert add(2, 3) == 5
6
7def test_add_negative_numbers():
8    assert add(-2, -3) == -5
9
10def test_divide_by_zero_raises():
11    with pytest.raises(ZeroDivisionError):
12        divide(10, 0)

Drei Tests: Standardfall (2+3=5), Edge-Case (negative Zahlen), Fehlerfall (Division durch Null muss Exception werfen). Das ist guter Test-Stil: jeder Test prüft eine konkrete Sache. Name ist sprechend – man weiß ohne Reinzuschauen was getestet wird.

3) Das AAA-Muster: Arrange, Act, Assert

Ein bewährtes Muster für lesbare Tests: jeder Test hat drei Phasen, deutlich getrennt:

aaa.pyPython

1def test_warenkorb_summe():
  # Arrange: Setup vorbereiten
  warenkorb = Warenkorb()
  warenkorb.hinzufuegen(Produkt("Buch", 19.99))
  warenkorb.hinzufuegen(Produkt("Stift", 2.50))
6
  # Act: das was getestet wird
  summe = warenkorb.gesamtsumme()
9
  # Assert: prüfen was rauskommt
  assert summe == 22.49

Wenn jeder Test diesem Muster folgt, sind sie leicht zu lesen und zu warten. Schau dir den Test an und du weißt sofort: was wird gesetzt, was wird gemacht, was wird geprüft.

4) Test-Frameworks pro Sprache

Die wichtigsten Test-Frameworks – meistens reichen schon die eingebauten Standards:

Test-Frameworks Übersicht

JUnit 5

Java-Standard. Annotations wie @Test, AssertJ für lesbare Asserts.

Java

pytest

Python-Favorit. Einfache assert-Syntax, viele Plugins.

Python

Jest

Facebook-Tool für JavaScript/TypeScript. Mocking eingebaut.

JS/TS

Vitest

Schneller Jest-Nachfolger, Vite-kompatibel.

JS/TS modern

xUnit / NUnit

.NET-Standard-Frameworks.

PHPUnit

Der PHP-Standard für Unit-Tests.

PHP

Cypress / Playwright

Modernste E2E-Tools für Web-Apps. Browser-Automation.

E2E

Selenium

Klassiker für E2E. Mächtig, aber alt und etwas umständlich.

E2E klassisch

Bei neuen Projekten heute: JUnit 5 für Java, pytest für Python, Vitest für moderne JS-Stacks, Playwright für E2E. Diese decken 90% der Use-Cases ab.

5) Code-Coverage: wie viel ist getestet?

Code-Coverage misst welcher Prozentsatz deines Codes durch Tests ausgeführt wird. Tools wie jacoco (Java), coverage.py (Python), istanbul (JS) generieren entsprechende Reports.

Beispiel Coverage-Report

user/UserService.java

92%

order/OrderController.java

78%

payment/PaymentGateway.java

45%

util/Helpers.java

100%

util/EmailSender.java

12%

Wichtig: Coverage ist kein Qualitäts-Maß. 100% Coverage heißt nur dass jede Zeile durchlaufen wurde – nicht dass die Tests sinnvoll sind. Ein Test ohne assert erhöht Coverage, prüft aber nichts. Realistisches Ziel: 70-80% Line-Coverage, mit Fokus auf kritische Pfade. PaymentGateway mit 45% wäre ein Warnsignal.

6) JUnit-XML: das universelle Report-Format

Praktisch alle Test-Frameworks können Reports im JUnit-XML-Format ausgeben. Diese Reports werden von CI-Tools wie GitHub Actions, GitLab CI und Jenkins direkt verarbeitet und im UI angezeigt:

Wie Test-Reports in CI/CD aussehen

247

Total

244

Passed

Failed

Skipped

✓UserServiceTest.test_create_user (0.05s)

✓UserServiceTest.test_delete_user (0.03s)

✗OrderServiceTest.test_apply_discount (1.2s) — AssertionError

✓OrderServiceTest.test_calculate_total (0.04s)

✗PaymentTest.test_credit_card (3.5s) — TimeoutException

In Pipeline-Konfigurationen sagst du dem CI-Tool, wo es nach den Reports suchen soll. GitHub Actions nutzt actions/upload-artifact, GitLab artifacts: reports: junit:, Jenkins junit 'target/surefire-reports/*.xml'. Das Tool zeigt dann Statistiken, Trend-Charts, schlägt Alarm bei neuen Failures.

7) Tests in der GitHub Actions-Pipeline

Hier ein konkretes Beispiel, wie Tests in eine GitHub Actions-Pipeline integriert werden:

.github/workflows/test.ymlYAML

1name: Tests
2
3on: [push, pull_request]
4
5jobs:
6  test:
7    runs-on: ubuntu-latest
8    steps:
9      - uses: actions/checkout@v4
10      - uses: actions/setup-python@v5
11        with: { python-version: "3.11" }
12
13      - run: pip install -r requirements.txt
14      - run: pytest --cov=src --cov-report=xml --junit-xml=results.xml
15
16      # Coverage zu Codecov senden
17      - uses: codecov/codecov-action@v4
18        with: { file: coverage.xml }
19
20      # Test-Ergebnisse in PR anzeigen
21      - uses: EnricoMi/publish-unit-test-result-action@v2
22        if: always()
23        with: { files: results.xml }

Der Workflow läuft Tests mit Coverage, sendet Coverage an Codecov.io (kostenlos für Open Source), und zeigt Test-Ergebnisse direkt im Pull Request mit grünen/roten Checks.

8) Test-Strategien für Integration-Tests

Integration-Tests brauchen oft echte Dependencies wie Datenbanken oder externe APIs. Es gibt mehrere Strategien wie man damit in CI/CD umgeht:

Strategie	Wie	Wann
Mock	Fake-Implementierungen statt echter Services	Wenn der Service eh nicht im Fokus steht
In-Memory	SQLite statt PostgreSQL, In-Memory-Caches	Für schnelle DB-Tests
TestContainers	Docker-Container für echte Services (Postgres, Redis, Kafka)	Für realistische Integration-Tests
Stubs	Vorgefertigte Antworten für HTTP-Mocks (WireMock)	Für externe APIs
Service Virtualization	Komplettes Faken externer Systeme	Enterprise mit vielen Abhängigkeiten

TestContainers ist heute die populärste Lösung für realistische Integration-Tests – Java-Bibliothek (mittlerweile auch für andere Sprachen), die Docker-Container für Tests startet:

UserRepositoryTest.javaJava + TestContainers

1@Testcontainers
2class UserRepositoryTest {
3    @Container
4    static PostgreSQLContainer postgres = new PostgreSQLContainer("postgres:15");
5
6    @Test
7    void testSaveUser() {
8        // echter PostgreSQL läuft im Docker-Container!
9        userRepo.save(new User("alice"));
10        assertEquals(1, userRepo.count());
11    }
12}

Vor dem Test startet automatisch ein Postgres-Container. Tests laufen gegen echte Datenbank. Nach den Tests wird der Container gestoppt. Realistisch wie Production, ohne externe Abhängigkeiten.

9) Das Problem: flaky Tests

Ein häufiges Problem in CI/CD: flaky Tests. Das sind Tests, die manchmal grün und manchmal rot sind, ohne dass sich der Code ändert. Sie sind ein riesiges Übel – Entwickler fangen an die Test-Ergebnisse zu ignorieren („Achso, dieser Test ist eh flaky, einfach nochmal laufen lassen").

⚠ Häufige Ursachen für flaky Tests

Warum sind Tests instabil?

Zeitabhängigkeiten: Thread.sleep(100) – mal reicht's, mal nicht
Race Conditions: zwei Threads die sich gegenseitig stören
Externe Services: Netzwerk-Timeouts, langsame APIs
Reihenfolge-Abhängigkeit: Test A funktioniert nur wenn Test B vorher lief
Geteilter Zustand: Static-Variables, gemeinsame DB-Tables
Datums-Bugs: Test funktioniert bis zur Zeitumstellung oder am Wochenende
UI-Tests: Element noch nicht gerendert, Animation noch nicht fertig

Best Practice: flaky Tests aggressiv jagen und fixen. Ein Test der zweimal pro Woche fehlschlägt, wird ignoriert – und wenn er irgendwann mal echte Bugs findet, vertraut keiner mehr. Tools wie pytest-rerunfailures markieren flaky Tests, aber das ist nur ein Pflaster.

10) Quality Gates und Test-Strategien

In professionellen Pipelines sind Tests verbunden mit Quality Gates – Schwellenwerten die erfüllt sein müssen:

Test-Pass: alle Tests grün, sonst Pipeline-Abbruch (Standard)
Coverage-Threshold: mindestens 80% Coverage – sonst Fail
Coverage darf nicht sinken: Diff-Coverage prüft neuer Code >= 90%
Maximale Test-Dauer: einzelne Tests über 5 Sekunden → Warnung
Keine Skipped Tests: bei Production-Branch erlaubst du keine @Ignore
Mutation Testing: PIT/Stryker simulieren Bugs, prüfen ob Tests sie finden

Bei GitLab sind Quality Gates über SonarQube-Integration üblich. Bei GitHub Actions über Branch Protection Rules: man kann definieren, dass bestimmte Checks grün sein müssen bevor man mergen darf.

11) Test-Pipeline-Optimierung

Wenn deine Tests die Pipeline ausbremsen, hier die wichtigsten Optimierungen:

Parallelisieren: Tests auf mehrere CPU-Kerne (pytest -n auto) oder Runner verteilen
Test-Splitting: Test-Suite auf mehrere Jobs aufteilen die parallel laufen
Test-Selection: nur Tests laufen lassen die zu geänderten Files passen
Fail Fast: bei erstem Fehlschlag abbrechen, statt alle Tests durchlaufen zu lassen
Caching: Test-Datenbank-Snapshots, Build-Artefakte zwischen Runs cachen
Smoke-Tests zuerst: schnelle „läuft überhaupt was?"-Tests vor den langen
Slow Tests aussondern: separater Job für Tests > 30s, läuft nur nightly

Faustregel: Tests sollten unter 10 Minuten dauern. Wenn länger, splitte sie auf oder optimiere. Eine 30-Minuten-Test-Pipeline frustriert Entwickler und sie umgehen sie irgendwann.

Zusammenfassung

Automatisierte Tests sind das Sicherheitsnetz jeder CI/CD-Pipeline. Test-Pyramide: viele schnelle Unit-Tests (75-80%), einige Integration-Tests (15-20%), wenige langsame E2E-Tests (5%). AAA-Pattern: Arrange-Act-Assert für lesbare Tests. Frameworks: JUnit (Java), pytest (Python), Jest/Vitest (JS), Playwright/Cypress (E2E). Coverage messen mit jacoco/coverage.py/istanbul – Ziel 70-80%, kein Selbstzweck. JUnit-XML ist das universelle Report-Format das alle CI-Tools verstehen. TestContainers für realistische Integration-Tests mit echten DBs in Docker. Flaky Tests aggressiv jagen und fixen – sonst verliert das Team Vertrauen. Quality Gates mit Coverage-Thresholds, Test-Pass-Rate, max. Test-Dauer. Optimierung: Parallelisierung, Test-Splitting, Caching. Pflichtwissen für jeden Entwickler.