Automatisierte Tests dank Gitlab CI
Dankenswerterweise gibt es heutzutage Hilfsmittel, die diese Schritte automatisiert durchführen können. So muss am Ende (im besten Fall) nur noch auf ein grünes Häkchen geachtet werden, um zu sehen, ob die Software funktioniert. Anhand eines Beispielprojektes möchte ich in diesem Beitrag die Gitlab CI vorstellen.
Unser Beispielprojekt
In der Gitlab CI lassen sich beliebige Befehle ausführen. Somit ist sie nicht an die Verwendung einer bestimmten Programmiersprache oder eines Frameworks gebunden ist. In diesem Beispiel wird ein kleines „Hallo Welt“ Python-Skript betrachtet, das mithilfe des Python Moduls "unittest" getestet werden soll.
greeter.py:
#!/usr/bin/python3
class Greeter:
def __init__(self, name, gender=None):
self.name = name
if gender == "male":
self.gender_greeting = "Herr"
elif gender == "female":
self.gender_greeting = "Frau"
else:
self.gender_greeting = None
def greet(self):
if self.gender_greeting is not None:
return "Hallo, " + self.gender_greeting + " " + self.name + "!"
else:
return "Hallo, " + self.name + "!"
test_greeter.py:
#!/usr/bin/python3
import unittest
from greeter import Greeter
class testGreeter(unittest.TestCase):
def test_GreeterMale(self):
self.assertEqual(Greeter(name="Max Mustermann", gender="male").greet(), "Hallo, Herr Max Mustermann!")
def test_GreeterFemale(self):
self.assertEqual(Greeter(name="Erika Mustermann", gender="female").greet(), "Hallo, Frau Erika Mustermann!")
def test_GreeterNoGender(self):
self.assertEqual(Greeter(name="Alex Mustermann").greet(), "Hallo, Alex Mustermann!")
Unser Modul enthält die Klasse Greeter. Diese nimmt zwei Parameter an: Name und optional das Geschlecht. Die Funktion greet() erstellt eine kurze Begrüßung. Wenn ein Geschlecht angegeben ist, wird auch die korrekte Anrede benutzt. Die Tests überprüfen, ob in jedem Fall der richtige Name und die richtige Anrede benutzt werden.
Die Gitlab CI für das Projekt konfigurieren
Ohne Änderungen an den Projekteinstellungen vornehmen zu müssen, ist die Gitlab CI in jedem Projekt standardmäßig betriebsbereit. Die Gitlab-Instanz eures Projektes muss jedoch sogenannte Runner eingerichtet haben, die die CI ausführen können. Wie solche Runner eingerichtet werden, ist in der offiziellen Gitlab Dokumentation beschrieben.
Was die CI tun soll, wird in einer Konfigurationsdatei namens gitlab-ci.yml definiert, die im Hauptverzeichnis des Repositorys angelegt wird:
gitlab-ci.yml:
stages: # Phasen der CI. Jobs in der gleichen Phase werden parallel ausgeführt.
- test
unittest: # Name des Jobs.
stage: test # Welcher Phase der Job angehört.
image: python:3.8 # Welches Docker Image benutzt wird.
script: # Befehle, die ausgeführt werden sollen.
- python3 -m unittest -v
Ab nun werden die Tests bei jedem Commit ausgeführt und das Ergebnis wird in der Gitlab-Oberfläche angezeigt.
Der grüne Haken besagt, dass die CI für diesen Commit erfolgreich ist. Auch in Merge Requests werden die Ergebnisse angezeigt.
In diesem Fall ist der Test fehlgeschlagen. Standardmäßig lässt Gitlab den Merge zwar zu, in den Projekteinstellungen bezüglich Merge Requests lässt sich jedoch konfigurieren, ob Gitlab bei fehlgeschlagener CI den Merge verweigern soll. Dadurch ließe sich sicherstellen, dass nur erfolgreich getestete Commits in den Hauptzweig gelangen.
Gitlab CI bei Mittwald
Bei Mittwald nutzen wir die vielfältigen Möglichkeiten der Gitlab CI sehr intensiv. Shellskripte zum Beispiel werden automatisch durch das Tool "shellcheck" auf mögliche Fehler untersucht. Ansible Playbooks werden einem Syntax Check unterzogen. Und auch unsere in Python geschriebenen Skripte werden durch das Modul "unittests" geprüft. Aber wir führen nicht nur Tests damit durch, sondern lassen auch die Images für einige unserer Server von der CI bauen. Zudem nutzen wir die Möglichkeit, Images für Container bauen zu lassen und automatisch in die integrierte Docker Registry zu schieben.
Fazit
Durch die Gitlab CI ist es uns möglich, viele manuelle Schritte zu automatisieren. Dadurch gewinnen wir mehr Zeit für neue Entwicklungen. Diese Automatisierung verhindert auch, dass ungetestete Commits in den Hauptbranch gelangen und sich dadurch Fehler einschleichen, die eigentlich schon getestet wurden. Manuelles Testen wird vermieden und auch Reviewer können sich darauf verlassen, dass der Code getestet wurde. Wenn die CI Fehler gefunden hat, kann der Programmierer diese sofort beheben, ohne erst auf ein Review warten zu müssen.
Der Aufwand zum Einrichten der Gitlab CI lohnt sich also und ist eine gute Investition für zukünftige Zeitersparnisse und Zufriedenheit sowohl beim Programmierer als auch beim Kunden.
Solltet ihr nun Lust auf die Gitlab CI bekommen haben, empfehle ich euch, auch einen Blick in die offizielle Dokumentation zu werfen. Der Quellcode des Beispielprojektes ist in der öffentlichen Instanz von gitlab.com zu finden.
Und nun viel Spaß beim Einrichten. ;-)
