40 Integration von Unit-Tests in die Pipeline

Unit-Tests sind ein wesentlicher Bestandteil jeder robusten Continuous Integration (CI)-Pipeline. Sie ermöglichen es Entwicklern, frühzeitig Fehler im Code zu erkennen und sicherzustellen, dass Änderungen keine unerwarteten Auswirkungen auf bestehende Funktionen haben. In diesem Kapitel lernst du, wie Unit-Tests in die GitLab CI/CD-Pipeline integriert werden und wie du Tests automatisch ausführst, sobald neue Commits gepusht oder Merge Requests erstellt werden.

40.1 Was sind Unit-Tests?

Unit-Tests sind automatisierte Tests, die einzelne Komponenten oder “Units” deines Codes isoliert testen. Sie stellen sicher, dass jede Komponente wie erwartet funktioniert und dienen als erste Verteidigungslinie gegen Fehler, bevor der Code in die Staging- oder Produktionsumgebung gelangt.

Beispiele für Unit-Tests: - Testen einzelner Funktionen oder Methoden. - Überprüfen von Rückgabewerten bestimmter Eingaben. - Validierung der Fehlerbehandlung.

40.2 Definition eines Test-Jobs in `.gitlab-ci.yml`

Unit-Tests können in der Pipeline als separater Test-Job definiert werden. Dies stellt sicher, dass der Code nur dann in die nächsten Pipeline-Stages übergeht (z. B. Deployment), wenn alle Tests erfolgreich abgeschlossen wurden.

Beispiel:

stages:
  - build
  - test
  - deploy

test_job:
  stage: test
  script:
    - npm install
    - npm run test

In diesem Beispiel wird der Job test_job in der test-Stage ausgeführt. Er installiert die notwendigen Abhängigkeiten über npm install und führt anschließend die Tests mit dem Befehl npm run test aus. Dieser Job wird ausgeführt, nachdem der Build-Job erfolgreich abgeschlossen wurde, und die Pipeline fährt nur fort, wenn die Tests bestanden werden.

40.2.1 Integrieren von Unit-Tests für verschiedene Programmiersprachen

Die Integration von Unit-Tests hängt stark von der verwendeten Programmiersprache und dem zugehörigen Test-Framework ab. Hier sind einige Beispiele, wie du Unit-Tests in typischen Umgebungen konfigurierst.

JavaScript mit Jest oder Mocha:
- Stelle sicher, dass npm test als Befehl in deinem Job ausgeführt wird. Verwende dazu ein Framework wie Jest oder Mocha.
Beispiel für Jest:
```
test_job:
  stage: test
  script:
    - npm install
    - npm run test -- --coverage
```
Hier wird die Testabdeckung (Coverage) ebenfalls überprüft, was einen Überblick darüber gibt, wie viel des Codes durch die Tests abgedeckt ist.
Python mit pytest:
- In Python-Projekten ist pytest eines der beliebtesten Test-Frameworks. Die Tests werden in Dateien definiert, die mit test_ beginnen, und können einfach über den pytest-Befehl ausgeführt werden.
Beispiel für pytest:
```
test_job:
  stage: test
  script:
    - pip install -r requirements.txt
    - pytest
```
In diesem Job werden die Abhängigkeiten installiert und anschließend pytest ausgeführt, um alle Tests im Projekt auszuführen.
Java mit JUnit:
- Java-Projekte verwenden häufig JUnit oder TestNG für Unit-Tests. Diese Tests können im Rahmen eines Maven- oder Gradle-Builds integriert werden.
Beispiel für Maven:
```
test_job:
  stage: test
  script:
    - mvn clean test
```
Hier wird Maven verwendet, um alle JUnit-Tests im Projekt auszuführen.

40.3 Test Coverage und Qualitätsüberwachung

Viele CI/CD-Tools bieten die Möglichkeit, den Test Coverage-Bericht zu generieren, der zeigt, wie viel Prozent des Codes durch die Unit-Tests abgedeckt sind. Dies ist ein nützliches Maß, um sicherzustellen, dass der Code ausreichend getestet wird.

Beispiel zur Berichterstellung für Coverage:

test_job:
  stage: test
  script:
    - npm install
    - npm run test -- --coverage
  artifacts:
    reports:
      cobertura: coverage/cobertura-coverage.xml

In diesem Beispiel wird ein Cobertura-Bericht erzeugt, der die Testabdeckung dokumentiert. Dieser Bericht kann in GitLab angezeigt werden, um die Abdeckung zu überwachen.

40.4 Fehlerbehandlung und Pipeline-Status

Wenn ein Unit-Test fehlschlägt, wird der entsprechende Job als fehlgeschlagen markiert, und die Pipeline stoppt. Dies ist eine wichtige Methode, um sicherzustellen, dass nur qualitativ hochwertiger und getesteter Code in die Produktion gelangt.

Tipp: Verwende allow_failure: true, wenn du einen Job definieren möchtest, dessen Fehlschlagen die Pipeline nicht blockiert, z. B. bei experimentellen Tests.